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Abstract. An XML web service is, to a first approximation, an RPC service in which requests and re- 
sponses are encoded in XML as SOAP envelopes, and transported over HTTP. We consider the problem 
of authenticating requests and responses at the SOAP-level, rather than relying on transport-level security. 
We propose a security abstraction, inspired by earlier work on secure RPC, in which the methods exported 
by a web service are annotated with one of three security levels: none, authenticated, or both authenticated 
and encrypted. We model our abstraction as an object calculus with primitives for defining and calling 
web services. We describe the semantics of our object calculus by translating to a lower-level language with 
primitives for message passing and cryptography. To validate our semantics, we embed correspondence as- 
sertions that specify the correct authentication of requests and responses. By appeal to the type theory for 
cryptographic protocols of Gordon and Jeffrey's Cryptyc, we verify the correspondence assertions simply by 
typing. Finally, we describe an implementation of our semantics via custom SOAP headers. 
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1. Introduction 

It is common to provide application-level developers with security abstractions that hide detailed imple- 
mentations at lower levels of a protocol stack. For example, the identity of the sender of a message may 
be exposed directly at the application-level, but computed via a hidden, lower level cryptographic protocol. 
The purpose of this paper is to explore how to build formal models of such security abstractions, and how to 
validate their correct implementation in terms of cryptographic primitives. Our setting is an experimental 
implementation of SOAP security headers for XML web services. 
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1.1. Motivation: Web Services and SOAP 

A crisp definition, due to the builders of the TerraService.NET service, is that "a web service is a web site 
intended for use by computer programs instead of human beings" [8]. Each request to or response from 
a web service is encoded in XML as a SOAP envelope [12]. An envelope consists of a header, containing 
perhaps routing or security information, and a body, containing the actual data of the request or response. 
A promising application for web services is to support direct retrieval of XML documents from remote 
databases, without resorting to unreliable "screen scraping" of data from HTML pages. For example, Google 
already offers programmatic access to its database via a web service [20]. Another major application is to 
support systems interoperability within an enterprise's intranet. 

The interface exported by a web service can be captured as an XML-encoded service description, in 
WSDL format [14], that describes the methods — and the types of their arguments and results — that make 
up the service. Tools exist for application-level developers to generate a WSDL description from the code 
of a service, and then to generate proxy code for convenient client access to the web service. Like tools for 
previous RPC mechanisms, these tools abstract from the details of the underlying messaging infrastructure. 
They allow us to regard calling a web service, for many if not all purposes, as if it were invoking a method 
on a local object. Our goal is to augment this abstraction with security guarantees. 

There are many signs of fervour over web services: there is widespread tool support from both open 
source and commercial software suppliers, and frequent news of progress of web service standards at bodies 
such as OASIS and the W3C. Many previous systems support RPC, but one can argue that what's new 
about web services is their combination of vendor-neutral interoperability, internet-scale, and toolsets for 
"mere mortals" [8]. Still, there are some reasons for caution. The XML format was not originally designed 
for messaging; it allows for interoperability but is inefficient compared to binary encodings. Moreover, it 
would be useful to use web services for inter-organisational communication, for example, for e-commerce, 
but SOAP itself does not define any security mechanisms. 

In fact, there is already wide support for security at the transport-level, that is, for building secure web 
services using HTTPS and SSL. Still, SSL encrypts all traffic between the client and the web server, so that 
it is opaque to intermediaries. Hence, messages cannot be monitored by firewalls and cannot be forwarded by 
intermediate untrusted SOAP-level routers. There are proposals to avoid some of these difficulties by placing 
security at the SOAP-level, that is, by partially encrypting SOAP bodies and by including authenticators, 
such as signatures, in SOAP headers. In particular, the WS-Security [6] specification describes an XML 
syntax for including such information in SOAP envelopes. 

Hence, the immediate practical goal of this work is to build and evaluate an exploratory system for 
SOAP-level security. 

1.2. Background: Correspondences and Spi 

Cryptographic protocols, for example, protocols for authenticating SOAP messages, are hard to get right. 
Even if we assume perfect cryptography, exposure to various replay and impersonation attacks may arise 
because of flaws in message formats. A common and prudent procedure is to invite expert analysis of any 
protocol, rather than relying on security through obscurity. Moreover, it is a useful discipline to specify and 
verify protocol goals using formal notations. Here, we specify authenticity goals of our protocol using Woo 
and Lam's correspondence assertions [37], and verify them, assuming perfect cryptography in the sense of 
Dolev and Yao [17], using type theories developed as part of the Cryptyc project [22, 23, 21]. 

Woo and Lam's correspondence assertions [37] are a simple and precise method for specifying authenticity 
properties. The idea is to specify labelled events that mark progress through the protocol. There are two 
kinds: begin-events and end-events. The assertion is that every end-event should correspond to a distinct, 
preceding begin-event with the same label. For example, Alice performs a begin-event with label "Alice 
sending Bob message M" at the start of a session when she intends to send M to Bob. Upon receiving M 
and once convinced that it actually comes from Alice, Bob performs an end-event with the same label. If 
the correspondence assertion can be falsified, Bob can be manipulated into thinking a message comes from 
Alice when in fact it has been altered, or came from someone else, or is a replay. On the other hand, if the 
correspondence assertion holds, such attacks are ruled out. 

There are several techniques for formally specifying and verifying correspondence assertions. Here, we 
model SOAP messaging within a process calculus, and model correspondence assertions by begin- and end- 
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statements within the calculus. We use a form of the spi-calculus [22], equipped with a type and effect 
system able to prove by typechccking that correspondence assertions hold in spite of an arbitrary attacker. 
Spi [5] is a small concurrent language with primitives for message passing and cryptography, derived from 
the 7r-calculus [32]. 

1.3. Contributions of this Paper 

Our approach is as follows: 

• Section 2 describes our high-level abstraction for secure messaging. 

• Section 3 models the abstraction as an object calculus with primitives for creating and calling web 
services. 

• Section 4 defines the semantics of our abstraction by translating to the spi-calculus. Correspondence 
assertions specify the authenticity guarantees offered to caller and callee, and are verified by typechecking. 

• Section 5 describes a SOAP-based implementation using Visual Studio .NET. 

• Section 6 shows how we can accommodate public-key infrastructures to implement the abstraction of 
Section 2. 

Our main innovation is the idea of formalizing the authentication guarantees offered by a security abstrac- 
tion by embedding correspondence assertions in its semantics. On the other hand, our high-level abstraction 
is fairly standard, and is directly inspired by work on secure network objects [35]. Although the rather 
detailed description of our model and its semantics may seem complex, the actual cryptographic protocol 
is actually quite simple. Still, we believe our framework and its implementation are a solid foundation for 
developing more sophisticated protocols and their abstractions. 

Many formal details, as well as the proofs of our formal results, have been relegated to the appendices. 
Specifically, Appendix A gives sample messages exchanged during web service method calls using our ab- 
stractions, Appendix B gives a formal description of our object calculus, Appendix C gives a formal definition 
of the spi-calculus used in the paper, Appendix D gives the proofs of our formal results, and Appendix E 
describes an extension of our object calculus to capture a form of first-class web services. 

A part of this article, in preliminary form, appears as a conference paper [24]. 

2. A Security Abstraction 

We introduce a security abstraction for web services, where the methods exported by a web service are 
annotated by one of three security levels: 



A call from a client to a web service is made up of two messages, the request from the client to the web 
service, and the response from the web service to the client. The inspiration for the security levels, and the 
guarantees they provide, comes from SRC Secure Network Objects [35]. An authenticated web method call 
provides a guarantee of integrity (that the request that the service receives is exactly the one sent by the 
client and that the response that the client receives is exactly the one sent by the service as a response 
to this request) and at-most-once semantics (that the service receives the request most once, and that the 
client receives the response at most once) . An authenticated and encrypted web method call provides all the 
guarantees of an authenticated call, along with a guarantee of secrecy (that an eavesdropper does not obtain 
any part of the method name, the arguments, or the results of the call). 

We use the language C^ to present our security abstraction. (There is nothing specific to C^ in our 
approach, although the implementation we describe in this section and in Section 5 takes advantage of 
some features of the language.) In C#, where users can specify attributes on various entities, our security 
annotations take the form of an attribute on web methods, that is, the methods exported by a web service. 
The attribute is written [SecurityLevel (.level)"] , where level is one of None, Auth, or AuthEnc. For example, 
consider a simple interface to a banking service, where [WebMethod] is an attribute used to indicate a method 
exported by a web service: 



None 
Auth 
AuthEnc 



unauthenticated call 
authenticated call 
authenticated and encrypted call 
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class BankingServiceClass { 
string callerid; 

[WebMethod] [SecurityLevel (Auth)] 
public int Balance (int account) ; 

[WebMethod] [SecurityLevel (AuthEnc)] 
public string Statement (int account) ; 

[WebMethod] [SecurityLevel (Auth) ] 
public void Transfer (int source, 

int dest, 

int amount) ; 

} 

The annotations get implemented by code to perform the authentication and encryption, at the level 
of SOAP envelopes, transparently from the user. The annotations on the web service side will generate a 
method on the web service that can be used to establish a security context. This method will never be 
invoked by the user, but automatically by the code implementing the annotations. For the purpose of this 
paper, we assume a simple setting for authentication and secrecy, namely that the principals involved possess 
shared keys. Specifically, we assume a distinct key K pq shared between every pair of principals p and q. We 
use the key K pq when p acts as the client and q as the web service. (Notice that K pq is different from 
K qp .) It is straightforward to extend our approach to different settings such as public- key infrastructures or 
certificate-based authentication mechanisms (see Section 6). 

An authenticated call by p to a web method £ on a web service w owned by q with arguments u\, . . . , u n 
producing a result r uses the following protocol: 

p — > q : request nonce 
q -* P : n q 

p — > q : p, req(w, £(u\, . . . ,u n ), s,n q ),n p , Hash(req(w, £{u\, 
q — > p : q, res(w, £(r),s, n p ), Hash{res{w 1 £(r), s, n p ), K pq ) 

Here, Hash is a cryptographic hash function (a one-way message digest function such as MD5). We tag the 
request and the response messages to be able to differentiate them. We also tag the response with the name 
of the method that was originally called. We include a unique session tag s in both the request and response 
message to allow the caller p to match the response with the actual call that was performed. 

An authenticated and encrypted call by p to a web method < on a web service w owned by q with 
arguments m,...,u n producing a result r uses a similar protocol, with the difference that the third and 
fourth messages are encrypted using the shared key instead of signed: 

p — > q : request nonce 
q -> P ■ n q 

p^> q:p, {req(w, £(m, . . . , u n ), s, n q )} Kpq ,n p 
q^p:q, {res(w, £(r), s, n p )} Kpq 

To convince ourselves that the above protocols do enforce the guarantees prescribed by the security 
abstraction, we typically argue as follows. Let's consider the authenticated and encrypted case, the authenti- 
cated case being similar. When the web service w run by principal q receives a request w, £(ui, . . . , u n ), s, n q 
encrypted with K pq (q uses the identity p in the request to determine which key to use), it knows that 
only p could have created the message, assuming that the shared key K pq is kept secret by both p and q. 
This enforces the integrity of the request. Since the message also contains the nonce n q that the web service 
can check has never appeared in a previous message, it knows that the message is not a replayed message, 
hence enforcing at-most-once semantics. Finally, the secrecy of the shared key K pq implies the secrecy of the 
request. A similar argument shows that the protocol satisfies integrity, at-most-once-semantics, and secrecy 
for the response. 

What do we have at this point? We have an informal description of a security abstraction, we have 
an implementation of the abstraction in terms of protocols, and an informal argument that the guarantees 
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prescribed by the abstraction are enforced by the implementation. How do we make our security abstraction 
precise, and how do we ensure that the protocols do indeed enforce the required guarantees? In the next 
section, we give a formal model to make the abstraction precise. Then, we formalize the implementation by 
showing how to translate the abstractions into a lower level calculus that uses the above protocols. We use 
types to show that guarantees are formally met by the implementation, via correspondence assertions. 

3. A Formal Model 

We model the application-level view of authenticated messaging as an object calculus. Object calculi [1, 25, 
29] are object-oriented languages in miniature, small enough to make formal proofs feasible, yet large enough 
to study specific features. As in FJ [29], objects are typed, class-based, immutable, and deterministic. As in 
some of Abadi and Cardelli's object calculi [1], we omit subtyping and inheritance for the sake of simplicity. 
In spite of this simplicity, our calculus is Turing complete. We can define classes to implement arithmetic, 
lists, collections, and so on. 

To model web services, we assume there are finite sets Prin and WebService of principal identifiers and 
web service identifiers, respectively. We think of each w G WebService as a URL referring to the service; 
moreover, class(w) is the name of the class that implements the service, and owner(w) G Prin is the principal 
running the service. 

To illustrate this model, we express the banking service interface introduced in the last section in our calcu- 
lus. Suppose there are two principals Alice, Bob G Prin, and a web service w = http://bob.com/BankingService, 
where we have owner(w) = Bob and class(w) = BankingServiceClass. Suppose we wish to implement the 
Balance method so that given an account number, it checks that it has been called by the owner of the 
account, and if so returns the balance. If Alice's account number is 12345, we might achieve this as follows: 

class BankingServiceClass 
Id Callerld 

Num Balance(Num account) 
if account = 12345 then 

if this. Callerld = Alice then 100 else null 
else . . . 

There are a few points to note about this code. First, as in BIL [25], method bodies conform to a single 
applicative syntax, rather than there being separate grammars for statements and expressions. Second, while 
the C# code relies on attributes to specify exported methods and security levels, there are not attributes 
in our calculus. For simplicity, we assume that all the methods of a class implementing a web service are 
exported as web methods. Furthermore, we assume that all these exported methods are authenticated and 
encrypted, as if they had been annotated AuthEnc. (It is straightforward to extend our calculus to allow 
per-method annotations but it complicates the presentation of the translation in the next section.) 

Every class implementing a web service has exactly one field, named Callerld, which exposes the identity 
of the caller, and allows application-level authorisation checks. 

We write w:Balance( 12345) for a client-side call to method Balance of the service w. The seman- 
tics of such a web service call by Alice to a service owned by Bob is that Bob evaluates the local call 
new BankingServiceClass ( Alice). Balance (12345) as Bob. In other words, Bob creates a new object of the 
formnew BankingServiceClass (Alice) (that is, an instance of the class BankingServiceClass with Callerld set 
to Alice) and then calls the Balance method. This would terminate with 100, since the value of this. Callerld 
is Alice. (For simplicity, we assume every class in the object calculus has a single constructor whose argu- 
ments are the initial values of the object's fields.) This semantics guarantees to the server Bob that the field 
Callerld contains the identity of his caller, and guarantees to the client Alice that only the correct owner of 
the service receives the request and returns the result. 

In a typical environment for web services, a client will not invoke web services directly. Rather, a client 
creates a proxy object corresponding to the web service, which encapsulates the remote invocations. Those 
proxy objects are generally created automatically by the programming environment. Proxy objects are 
easily expressible in our calculus, by associating with every web service w a proxy class proxy (w). The class 
proxy (w) has a method for every method of the web service class, the implementation for which simply calls 
the corresponding web service method. The proxy class also has a field Id holding the identity of the owner 
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of the web service. Here is the client-side proxy class for our example service: 

class BankingServiceProxy 
Id Id() 
Bob 

Num Balance{Num account) 
w : Balance ( account) 

The remainder of this section details the syntax and informal semantics of our object calculus. 



3.1. Syntax 

In addition to Prin and WebService, we assume finite sets Class, Field, Meth of class, field, and method 
names, respectively. 

Classes, Fields, Methods, Principals, Web Services: 



c G Class 


class name 


f E Field 


field name 


i E Meth 


method name 


p E Prin 


principal name 


w E WebService 


web service name 


There are two kinds of data type: 


Id is the type of principal identifiers, and c G Class is the type of 


instances of class c. A method signature specifies the types of its arguments and result. 


Types and Method Signatures: 




A,B E Type ::= 


type 


Id 


principal identifier 


c 


object 


sig E Sig ::= B{A± xi,...,A n x n ) 


method signature (xi distinct) 



An execution environment defines the services and code available in the distributed system. In addition 
to owner and class, described above, the maps fields and methods specify the types of each field and the 

signature and body of each method, respectively. We write X — > Y and X — > Y for the sets of total functions 
and finite maps, respectively, from X to Y. 

Execution Environment: (fields , methods , owner , class) 

fields E Class — ► (Field ^5 Type) fields of a class 

methods E Class — > (Meth -5 Sig x Body) methods of a class 

owner E WebService — > Prin service owner 

class E WebService — > Class service implementation 

We complete the syntax by giving the grammars for method bodies and for values. 
Values and Method Bodies: 

i 1 

x,y,z name: variable, argument 

u,v E Value ::= value 

x variable 

null null 

new c(v\, . . . , v n ) object 

p principal identifier 

a, b E Body ::= method body 

v value 

let x~a in b let-expression 

if u — v then a else b conditional 
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v.£(ui, ...,u n ) 
w:£{ui, ...,«„) 



field lookup 
method call 
service call 



The free variables fv (a) of a method body are defined in the usual way, where the only binder is x being 
bound in b in the expression let x—a in b. We write a{x^-b} for the outcome of a capture-avoiding substitution 
of b for each free occurence of the variable x in method body a. We view method bodies as being equal up 
to renaming of bound variables. Specifically, we take let x—a in b to be equal to let x'—a in b{x^x'}, if 



Our syntax for bodies is in a reduced form that simplifies its semantics; in examples, it is conve- 
nient to allow a more liberal syntax. For instance, let the term if a\ = ai then b\ else 62 be short for 
let xi—ai in let X2=ci2 in if x\ = X2 then b\ else 62. We already used this when writing if this. Caller Id = 
Alice then 100 else null in our example. Similarly, we assume a class Num for numbers, and write integer 
literals such as 100 as shorthand for objects of that class. 

Although objects are values, in this calculus, web services are not. This reflects the fact that current 
WSDL does not allow for web services to be passed as requests or results. We explore an extension of our 
model to account for web services as "first-class values" in Appendix E. 

We assume all method bodies in our execution environment are well-typed. If methods (c)(£) = (sig, b) and 
the signature sig = B(A\ x\, . . . , A n x n ) we assume that the body b has type B given a typing environment 
this:c, xi:A\, . . . , x n :A n . The variable this refers to the object on which the I method was invoked. The type 
system is given by a typing judgment E h a : A, saying that a has type A in an environment E of the form 
X\ --^i •)••••! '-^-n t licit gives a type to the free variables in a. The domain dom(E) of E is the set of variables 
{xi, . . . ,x n } given a type in E. The typing rules, which are standard, are given in Appendix B. We also 
assume the class class(w) corresponding to each web service w has a single field callerid. 



3.2. Informal Semantics of our Model 

We explain informally the outcome of evaluating a method body b as principal p, that is, on a client or server 
machine controlled by p. (Only the semantics of web service calls depend on p.) A formal account of this 
semantics, as well as the typing rules of the calculus, can be found in Appendix B. 

To evaluate a value v as p, we terminate at once with v itself. 

To evaluate a let-expression let x—a in b as p, we first evaluate a as p. If a terminates with a value v, we 
proceed to evaluate b{x^v}, that is, b with each occurrence of the variable x replaced with v. The outcome 
of evaluating b{x<—v} as p is the outcome of evaluating the whole expression. 

To evaluate a conditional if u = v then a else b as p, we evaluate a as p if u and v are the same; else we 
evaluate b as p. 

To evaluate a field lookup v.f as p, when v is an object value new c{v\, . . . , v n ), we check / is the jth 
field of class c for some j £ l..n (that is, that fields(c) = fi Ai * el - n and that / = /j), and then return 
Vj. If v is null or if the check fails, evaluation has gone wrong. 

To evaluate a method call v.i(u\, . . . , u n ) as p, when v is an object new c(v\, . . . , v n ), we check I is a 
method of class c (that is, that methods(c) = li *—> (sig i ,bi) 4<E1 - m and that t — £j for some j £ l..m) and 
we check the arity of its signature is n (that is, that sig^ = B(Ai x\, . . . , A n x n )) and then we evaluate the 
method body as p, but with the object v itself in place of the variable this, and actual parameters u\, . . . , 
u n in place of the formal parameters x\, . . . , x n (that is, we evaluate the expression bi{this^v, xi^u\, . . . , 
x n ^u n }). If v is null or if either check fails, evaluation has gone wrong. 

To evaluate a service call w:£(ui, . . . , u n ) as p, we evaluate the local method call new c(p)l(ui, . . . , u n ) 
as q, where c = class(w) is the class implementing the service, and q — owner (w) is the principal owning the 
service. (By assumption, c's only field is Callerid of type Id.) This corresponds directly to creating a new 
object on q's web server to process the incoming request. 



x'?fv(b). 
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4. A Spi-Calculus Semantics 

We confer a formal semantics on our calculus by translation to the spi-calculus [5, 22], a lower- level language 
with primitives for message-passing (to model SOAP requests and responses) and cryptography (to model 
encryption and decryption of SOAP headers and bodies) . 

4.1. A Typed Spi-Calculus (Informal Review) 

To introduce the spi-calculus, we formalize the situation where Alice sends a message to Bob using a 
shared key, together with a correspondence assertion concerning authenticity of the message, as outlined 
in Section 1. A name is an identifier that is atomic as far as our analysis is concerned. In this exam- 
ple, the names Alice and Bob identify the two principals, the name K represents a symmetric key known 
only to Alice and Bob, and the name n represents a public communication channel. A message, M or 
N, is a data structure such as a name, a tuple (M\, . . . , M n ), a tagged message t(M), or a ciphertext 
{M}jv (that is, a message M encrypted with a key N, which is typically a name). A process, P or Q, 
is a program that may perform local computations such as encryptions and decryptions, and may com- 
municate with other processes by message-passing on named channels. For example, the process Pahcc = 
begin s ending (Alice, Bob, M); out n {M}k defines Alice's behaviour. First, she performs a begin-event la- 
belled by the tagged tuple sending (Alice, Bob, M), and then she sends the ciphertext {M} K on the channel 
n. The process Psob — inp n (a;); decrypt x is {j/}i<-;end s ending (Alice, Bob, y); defines Bob's behaviour. He 
blocks till a message x arrives on the channel n. Then he attempts to decrypt the message with the key K. 
We assume there is sufficient redundancy, such as a checksum, in the ciphertext that we can tell whether 
it was encrypted with K. If so, the plaintext message is bound to y, and he performs an end-event labelled 
sending (Alice, Bob, y). The process new (K); (Paucb I PBob) defines the complete system. The composition 
P Alice | PBob represents Alice and Bob running in parallel, and able to communicate on shared channels such 
as n. The binder new(K) restricts the scope of the key K to the process Paucc | Psob so that no external 
process may use it. Appendix C contains the grammar of spi messages and processes. The grammar includes 
the type annotations that are required to appear in spi terms. 

We include begin- and end-events in processes simply to specify correspondence assertions. We say a 
process is safe to mean that in every run, and for every L, there is a distinct, preceding begin L event for 
every end L event. Our example is safe, because Bob's end-event can only happen after Alice's begin-event. 

For correspondence assertions to be interesting, we need to model the possibility of malicious attacks. 
Let an opponent be a spi-calculus process O, arbitrary except that O itself cannot perform begin- or end- 
events. We say a process P is robustly safe if and only if P | O is safe for every opponent O. Our example 
system new (K); (PAUce \ PBob) is not robustly safe. The opponent cannot acquire the key K since its 
scope is restricted, but it can intercept messages on the public channel n and mount a replay attack. The 
opponent inp n (x); out n x; out n x duplicates the encrypted message so that Bob may mistakenly accept M 
and perform the end-event s ending (Alice, Bob, M) twice. To protect against replays, and to achieve robust 
safety, we can add a nonce handshake to the protocol. 

In summary, spi lets us precisely represent the behaviour of protocol participants, and specify authenticity 
guarantees by process annotations. Robust safety is the property that no opponent at the level of the spi- 
calculus may violate these guarantees. We omit the details here, but a particular type and effect system 
verifies robust safety: if a process can be assigned the empty effect, then it is robustly safe. The example 
above is simple, but the general method works for a wide range of protocol examples [22, 21]. 

For the sake of clarity, we defer some of the technical details to the appendices. Specifically, Appendix C 
contains more details on the spi-calculus and the type and effect sytem, as well as a formal definition of 
robust safety; Appendix D gives a proof of our technical results. 

4.2. A Semantics for Local Computation 

We translate the types, values, and method bodies of our object calculus to types, messages, and processes, 
respectively, of the spi calculus. To begin with, we omit web services. Many computational models can 
be studied by translation to process calculi; our translation of local computation follows a fairly standard 
pattern. 
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We use the notation [] to represent the translation of the types and terms of our object calculus to 
appropriate types, messages, and processes in the spi calculus. In many places, we also define abbreviations 
in the spi calculus (for instance, we define let x=ca\\ w (p, args);P as shorthand for a more complex spi calculus 
process); these do not use the [] notation. 

We assume that Prin are spi-calculus names, and that FieldLiMethL) Class U {null} are message tags. The 
translations for types is straightforward. Since principal identifiers arc presumably known to the opponent, 
the type of identifiers corresponds to the spi type Un. A value of class c is either the value null, or a tagged 
tuple new c(v\, . . . ,v n ). As we shall see below, we translate null to a tagged empty tuple null(), and an 
object to a tagged tuple c(vi, . . . ,v n ). Thus, a class c translates to a tagged union type with components 
null(Un) and c(Un). (The types Un indicate that the content of the tuples arc presumably known to the 
opponent.) 

Type Translation: 

i 1 

Prin = Un 

{Id} 4 Prin 

[c| = Union(miZZ(Un),c(Un)) 



Environment Translation: 

jx 1 :A 1 , . . .,x n :A n j = xi:[Ai], . . .,x n :[A n ] 

If As = A\, . . . ,A n and as = xi, ...,x n we sometimes write B(As xs) as shorthand for the signature 
B(Ai X\,...,A n x n ). We define two shorthands for types corresponding to web method calls. The type 
Req(w) represents the type of possible calls to web methods provided by the service w; the type of a call 
is simply the translated type of the arguments of the web method, tagged with the name of the method. 
Similarly, the type Res(w) represents the type of the results of web methods provided by the service w; the 
type of a result of a call is simply the translated type of the result of the web method, tagged once again 
with the name of the method. 



Request and Response Types: 



\A u ...,A m \ 4 [Ail, • ■ • > [An] 




Req(w) 4 Union(^([Aj]) iel " n ) 




where class(w) = c and methods (c) = ti i- 
Res(w) 4 Union(^([Bj]) <6l - n ) 


-> (Bi(AsiXSi), hi) iel -- n 




where class(w) — c and methods{c) 


{Bi(AsiXSi),bi) iel - n 



The translation of expressions really acts on the type derivation of an expression, not just the expression 
itself. This means that during the translation of an expression, we have access to the types of the subex- 
pressions appearing in the expression. To reduce clutter, we write the translation as though it is acting 
on the expression itself, except that when we need access to the type of a subexpression, we annotate the 
appropriate subexpression with its type. For example, the translation of let x—a in b depends on the type 
of a, which is available through the type derivation of E h let x=a in b : B. We write let x=cia in b to 
indicate that the type of a is A, according to the type derivation. Values translate easily; in particular, an 
object translates to a tagged tuple containing the values of its fields. 

Translation of a Value v to a Message flVfl: 

H = x 

[null} = nullQ 

{new c(vi, . . .,v n )j = c([vij, [v n ]) 

M=p | 

We translate a body b to a process [6]^ that represents the evaluation of b as principal p. The name k is 
a continuation, a communications channel on which we send \v\ to represent termination with value v. Since 
our focus is representing safety rather than liveness properties, we represent an evaluation that goes wrong 
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simply by the inactive process stop; it would be easy — but a complication — to add an exception mechanism. 
We use standard split and case statements to analyse tuples and tagged messages, respectively. To call a 
method £ of an object v of class c, with arguments m, . . . , u n we send the tuple (p, [u], [ui], . . . , [«„], k) on 
the channel cJL. The name p is the caller, and channel k is the continuation for the call. We translate method 
I of class c to a process that repeatedly awaits such messages, and triggers evaluations of its body. We defer 
the translation of web method calls until Section 4.3. Our translation depends in part on type information; 
we write v c in the translation of field lookups and method calls to indicate that c is the type of v. 

Translation of a Method Body b to a Process fbj^l: 

Ml = out k h 

{let x=a A in bf k 4 new (fc'illn); (Ja]£, | inp k' (x:Un); [b]*) 
[if u = v then a else bf k 4 if [ u ] = \v\ then \af k else \bf k 

\v c -fiYk — case M ' s null {y:\in); stop 

is c(y:Un); split y is (xi:|L4i], . . . , x„:[A n ]); out k xj 
where fields(c) = Ai » el -- n 5 and j e l..n 



\v c .£{u\, . . . , u n )\ p k = case [w] is null(y:Un); stop 




is c(y:Un); out c_l (p 


,H,[m],...,K],fc) 


Translation of Method £ of Class c: 


Idass(c,£) = repeat inp cJ (z:Un); 




split z is (p:Prin, t/iis:Un, ^ 


^:[,4„],fc:Un);[6K 


where methods (c)(£) = (B(A\ xi, . 





4.3. A Semantics for Web Services 

We complete the semantics for our object calculus by translating our cryptographic protocol for calling a 
web service to the spi-calculus. A new idea is that we embed begin- and end-events in the translation to 
represent the abstract authenticity guarantees offered by the object calculus. 

We assume access to all web methods is at the highest security level AuthEnc from Section 2, providing 
both authentication and secrecy. Here is the protocol, for p making a web service call w:£(ui, . . . ,u n ) to 
service w owned by q, including the names of continuation channels used at the spi level. Recall that the 
protocol assumes that the client has a way to query the web service for a nonce. Therefore, we assume that in 
addition to the methods of class (w), each web service also supports a method getnonce, which we implement 
specially. 

p — > q on w : req(getnonceQ) , k\ 
q — > p on ki : res(getnonce(n q )) 

p -> q on w : p, {req{w,£{u 1 , . . . , u n ), t, n q )} Kpq , n p , k 2 
q -^p on k 2 : q, {res(w,£(r),t,n p )} Kpq 

We are assuming there is a shared key K pq for each pair of principals p,g€ Prin. For the sake of brevity, 
we omit the formal description of the type and effect system [21] we rely on, but sec Appendix C for a 
detailed overview. Still, to give a flavour, we can define the type of a shared key K pq as follows: 

Type of Key Shared Between Client p and Server q: 

CSKey(p, q) = 
SharedKey(Union( 
req(w:Un, a:Un, i:Un, 

n g :Public Response [end req(p, q, w, a, t)]), 
res(w:Un, r:Un, i:Un, 

n p :Public Response [end res(p, q, w, r, t)]))) 



The type says we can use the key in two modes. First, we may encrypt a plaintext tagged req containing 
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four components: a public name w of a service, an argument a suitable for the service, a session tag t, and a 
nonce n q proving that a begin-event labelled req(j>, q, w, a, t) has occurred, and therefore that an end-event 
with that label would be safe. Second, we may encrypt a plaintext tagged res containing four components: a 
service w, a result r from that service, the session tag t, and a nonce n p proving that a begin-event labelled 
res(p, q, w, r, t) has occurred. 

We translate a service call to the client-side of our cryptographic protocol as follows. We start by em- 
bedding a begin-event labelled req(p, q, w, £(fui], . . . , [u„]), t) to record the details of client p's call to server 
q = owner(w). We request a nonce n q , and use it to freshen the encrypted request, which we send with our 
own nonce n p , which the server uses to freshen its response. If the response indeed contains our nonce, we 
embed an end-event to record successful authentication. For the sake of brevity, we rely on some standard 
shorthands for pattern-matching. 



Translation of Web Method Call: 

i 1 

\w:l{ui, . . -,u n )f k = 

new (fci:Un, fc 2 :Un, t:Ur\, n p :Public Challenge []); 
begin req(p,q,w, edmj, 
out w (req(getnonce()),ki); 
inp k\ (res(getnonce(n q :\Jn))); 

cast n q is (n^Public Response [end req(p, q, w, ^([mi], • • • , [u n ]), t)]); 
out w {p,{req{w,l{{u 1 \, {u n \),t 1 n' q )} Kpq ,n pi k 2 )] 
inp ki (<7':Un, bdy :(Jn); decrypt bdy is {res(plain)} K pq \ 

match plain is (w, rest:(r:Res(w), i'rlln, Public Response [end res(p,q,w,r,t')]))\ 
split rest is (r:Res(w),rest':(t':Un,n' p :Pub\\c Response [end res(p,q,w,r,t')]))\ 
match rest' is (t,n p :Pub\\c Response [end res(p,q,w,r,t)}); 
check n p is n' p ; end res(p 7 q, w, r, t); case r is £(x); out k x 
where q = owner(w) 



Our server semantics relies on a shorthand notation defined below; let x=ca\\ w (p, £{u\, . . . , u n ))\ P runs 
the method I of the class class(w) implementing the service w, with arguments u\, . . . , u n , and with its 
Callerld field set to p, binds the result to x and runs P. 



Server-Side Invocation of a Web Method: 

let x=ca\\ w {p, args);P = 
new (k); 

(case args (is £i(xsi); new (A/); (out cJLi (q, c(p),xsi, k') \ inp k' (r); out k £i(r))) iel " 

| inp k (x);P) 
where c = class (w), q = owner (w), 
and methods(c) =<;h (B i (As l ,xs i ),b l ) tel -- n 



Finally, we implement each service w by a process I ws (w). We repeatedly listen for nonce requests, reply 
with one, and then await a web service call freshened by the nonce. If we find the nonce, it is safe to 
perform an end-event labelled req(p, q, w, a, t), where p is the caller, q = owner (w) is the service owner, a is 
the received method request, and t is the session tag. We use the shorthand above to invoke a. If r is the 
result, we perform a begin-event labelled res(p, q,w,r,t) to record we are returning a result, and then send 
a response, freshened with the nonce we received from the client. In general, the notation n^ei n ^* means 

Pi I • • • I Pa- 
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Web Service Implementation: 

I W s{ w ) — repeat inp w (bdy.On, fci:Un); 
case bdy is req(getnonce(j): 
new (n 9 :Public Challenge []); 
out ki (res(getnonce(n q ))); 
inp w (p':Un, cipher:Ur\, n p :Un, A^Un); 

n pe p„„ if p = p' then 

decrypt cipher is {req{plain)} K pq ] 
match plain is (w, resi: 

(a:Req(w), i:Un, Public Response [end reg(p, q, w, a, t)])); 
split rest is (a:Req(w), t:Un, n' q : 

Public Response [end req(p,q,w,a,t)]); 
check n q is n' q ; end req(p, q, w, a, t); 
let r:Res(w)—ca\\ w {p, a); 
begin res(p, g, w, r, t); 

cast n p is in' Public Response [end res(p, q, w, r, t)]); out &2 {res(«;, r, t, n' )}ic pq ) 
where q = owner (w) 

This semantics is subject to more deadlocks than a realistic implementation, since we do not have a single 
database of outstanding nonces. Still, since we are concerned only with safety properties, not liveness, it is 
not a problem that our semantics is rather more nondctcrministic than an actual implementation. 



4.4. Security Properties of a Complete System 

We define the process Sys(b,p 7 k) to model a piece of code b being run by principal p (with continuation 
k) in the context of implementations of all the classes and web services in Class and WebService. The 
implementation of the classes and web services are given as follows. 

Implementation of Classes and Web Services: 

CIMeth = {(c,£) : c e Class, £e dom (methods (c))} 

Iclass — Yl(c,e)e CIMeth Iclass{c,£) 

jws = Ylwe WebService (w) ^ 

The process Sys(b,p,k) is defined with respect to an environment that specifies the type of its free 
variables, such as the names of the web services, principals, classes and methods, and keys. 

Top-Level Environments: 

E class 4 (cJ:Un) (c^ciMeth 1 
E keys 4 (K pq :CSKey{p,q)) ™ ePrm 

E ws = (w:\Jn) w^WebServzee 

E P rin =pi:Prin, . . . ,p„:Prin where Prin = {pi, . . . ,p n } 

Eq E ws , Ep r i n , E c i ass , Ek e y S 

The process Sys(b,p 7 k) is defined as follows: 

Sys(b,p,k) = new {E classi E keys ); (I class \ I ws \ new (fc:Un); {bjl) 

We claim that the ways an opponent O can interfere with the behaviour of Sys(b,p,k) correspond to the 
ways in which an actual opponent lurking on a network could interfere with SOAP-level messages being 
routed between web servers. The names cJL of methods are hidden, so O cannot interfere with calls to local 
methods. The keys K pq are also hidden, so O cannot decrypt or fake SOAP-level encryption. On the other 
hand, the names w on which Sys(b,p, k) sends and receives our model of SOAP envelopes are public, and so 
O is free to intercept, replay, or modify such envelopes. 
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Our main result is that an opponent cannot disrupt the authenticity properties embedded in our trans- 
lation. The proof is by showing the translation preserves types. 

Theorem 1. If h b : B and p e Prin and k £ dom(E ) then the system Sys(b,p, k) is robustly safe. 
Proof. See Appendix D.l. □ 

5. A SOAP-Level Implementation 

We have implemented the security abstraction introduced in Section 2 and formalized in Sections 3 and 4 
on top of the Microsoft Visual Studio .NET implementation of web services, as a library that web service 
developers and clients can use. A web service developer adds security attributes to the web methods of the 
service. The developer also needs to provide a web method to supply a nonce to the client. On the client 
side, the client writer is provided with a modified proxy class that encapsulates the implementation of the 
security abstraction and takes into account the security level of the corresponding web service methods. 
Hence, from a client's point of view, there is no fundamental difference between accessing a web service with 
security annotations and one without. 

Consider an implementation of our running example of a banking service. Here is what (an extract of) 
the class implementing the web service looks like: 

class BankingServiceClass : System. Web. Services. WebService 
{ 

[WebMethod] 

public int RequestNonce () { ... } 
public DSHeader header; 
[WebMethod] 

[Secur ityLevel (Level=SecLevel . Auth) ] 

[SoapHeader ( "header " , Direct ion=Direct ion. InOut ,Required=true)] 
public int Balance (int account) { . . . } 

} 

This is the code we currently have, and it is close to the idealized interface we gave in Section 2. The 
differences are due to implementation restrictions imposed by the development environment. The extract 
shows that the web service implements the RequestNonce method required by the authentication protocol. 
The Balance method is annotated as an authenticated method, and is also annotated to indicate that the 
headers of the SOAP messages used during a call will be available through the header field of the interface. 
(The class DSHeader has fields corresponding to the headers of the SOAP message.) As we shall see shortly, 
SOAP headers are used to carry the authentication information. Specifically, the authenticated identity of 
the caller is available in a web method through header . callerid. 

To implement the security abstraction on the web service side, we use a feature of Visual Studio .NET 
called SOAP Extensions. Roughly speaking, a SOAP Extension acts like a programmable "filter" . It can be 
installed on either (or both) of a client or a web service. It gets invoked on every incoming and outgoing 
SOAP message, and can be used to examine and modify the content of the message before forwarding it 
to its destination. In our case, the extension will behave differently according to whether the message is 
incoming or outgoing, and depending on the security level specified. For an outgoing message, if the security 
level is None, the SOAP message is unchanged. If the security level is Auth, messages are signed as specified 
by the protocol: a cryptographic hash of the SOAP body and the appropriate nonce is stored in a custom 
header of the messages. If the security level is AuthEnc, messages are encrypted as specified by the protocol, 
before being forwarded. For incoming messages, the messages are checked and decrypted, if required. If the 
security level is Auth, the signature of the message checked. If the security level is AuthEnc, the message is 
decrypted before being forwarded. Our implementation uses the SHA1 hash function for signatures, and the 
RC2 algorithm for symmetric encryption. 

To implement the security abstraction on the client side, we provide the client with a new proxy class. 
The new proxy class provides methods None, Auth, and AuthEnc, that are called by the proxy methods to 
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initiate the appropriate protocol. The method None simply sets up the headers of the SOAP message to 
include the identity of the caller and the callee. Auth and AuthEnc do the same, but also make a call to 
the web service to get a nonce and add it (along with a newly created nonce) to the headers. The actual 
signature and encryption of the SOAP message is again performed using SOAP Extensions, just as on the 
web service side. 

Our implementation uses a custom SOAP header DSHeader to carry information such as nonces, identities, 
and signatures. It provides the following elements: 



Not all of those elements are meaningful for all messages. In addition to these headers, in the cases where the 
message is encrypted, the SOAP body is replaced by the encrypted body. Appendix A gives actual SOAP 
messages exchanged between the client and web service during an authenticated call to Balance, and an 
authenticated and encrypted call to Statement. 

6. A Semantics Using Asymmetric Cryptography 

The security abstraction we describe in Section 2 relies on shared keys between principals. This is hardly 
a reasonable setup in modern systems. In this section, we show that our approach can easily accommodate 
public-key infrastructures. 

6.1. Authenticated Web Methods 

We start by describing the protocol and implementation for authenticated web methods. Hence, for now, we 
assume that all the exported methods of a web service are annotated with Auth. 

Consider a simple public-key infrastructure for digital signatures. Each principal p has a signing key SKp 
and a verification key VKp. The signing key is kept private, while the verification key is public. To bind the 
name of a principal with their verification key, we assume a certification authority CA (itself with a signing 
key SKCA and verification key VKCA) that can sign certificates CertVKp of the form VKp\}sKCA- 
(The notation {| • \}k is used to represent both asymmetric encryption and signature, differentiating it from 
symmetric encryption. In the case where {|M[}if represent a signature, this is simply notation for M along 
with a token representing the signature of M with asymmetric key K .) 

Here is a protocol that uses digital signatures to authenticate messages, for p making a web service call 
w.£(ui, . . . , u n ) to service w owned by q, including the names of continuation channels used at the spi level. 
Again, we assume that in addition to the methods of class (w), each web service also supports a method 
getnonce, which we implement specially. 

p — > q on w : CertVKp, n p , req(getnonceQ) , k\ 

q — > p on ki : CertVKq, res{getnonce{n q )) 

p -> q on w : p, §req{w,Z{ui, . . .,u n ),t,q, n q )\} S k p , k 2 

q -> p on k 2 : q, {|res(w, £(r), t,p, n p )\} S K q 

Type of Signing Keys: 



Union(re<z(u>:Un, a:Un, t:Un, q:Un, n 9 :Public Response [end req(p, q, w, a, t)]), 
res(w:Un, r:Un, t:Un, q:\Jn, n g :Public Response [end res(q,p, w, r, t)])) 
AuthKeys(p) = KeyPair(AuthMsg(p)) 
AuthCert = (p : Un, Decrypt Key(AuthMsg(p))) 
AuthCertKeys = KeyPair(AuthCert) 



We will represent the key pair of a signing key and verification key for principal p by a pair DSp, of type 



nq 

signature 



callerid 
calleeid 
np 



identity of the client 

identity of the web service provider 

client nonce 

web service nonce 

cryptographic signature of the message 



AuthMsg(p) 4 
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AuthKeys(p). The key pair for the certification authority will be represented by a pair DSC A. We use the 
following abbreviations: 



Key and Certificates Abbreviations: 

SKp = Encrypt (DSp) p's signing key 

VKp = Decrypt (DSp) p's verification key 

CertVKp = {\p, VKp |} sk ca p's certificate 



With that in mind, we can amend the translation of Section 4 to accommodate the new protocol. First, 
we give a new translation for a web method call wl(u\, . . . , u n ): 



New Translation of Web Method Call: 

i 1 

{W.e(u\, . . -,U n )f k = 

new (fci:lln, fc 2 :Un, t:Un, n p :Public Challenge []); 
begin req(p,q,w,i({u 1 \, [u„]),t); 
out w (CertVKp, n p , req(getnonceQ), k\); 
inp k\ (c:Ur\,res(getnonce(n g :Un))); 

decrypt c is {| cert:(q':(Jn, Decrypt Key(AuthMsg(g')))|}y^ Cj4 -i; 

match cert is (q, vkq: Decrypt Key(AuthMsg(<7))); 

cast n q is (n^tPublic Response [end req(p, q, u>, . . . , [u„]), t)]); 

out w (p,{\req(w,e(lu 1 j, . . . , [u n j), t, q, n' q )$ S K P , k 2 ); 

inp fc 2 (<7":Un, bdy:\Jn); 

decrypt bdy is {\res(plain:(w' :Ur\, r:Un, i':Un,p':Un, 

Public Response [end res(p', q, w' , r, t')]))\} vkq -i ; 
match plain is (w, rest :(r: Res (w), i':Un,p':lln, 

Public Response [end res(p' , q,w,r,t')])); 
split rest is (r : Res (w), rest' :(t':Un 7 p':{Jn, 

Public Response [end res(p' , q, w, r, t')])); 
match rest 1 is (t, rest":(p':Un, Public Response [end res(p', q, w, r, t)])); 
match rest" is (p,n' p :Pub\\c Response [end res(p,q,w,r,t)])\ 
check n p is n' p ; 
end res(p, q, w, r, t); 
case r is out k x 
where q — owner(w) 



We also need to give a new implementation for web services, again to take into account the different 
messages being exchanged: 



New Web Service Implementation: 

Iws (w) = 

repeat inp w (c:Un, n p :Un, bdy.Un, fci:Un); 
case bdy is req(getnonceQ); 

decrypt c is {\p:Ur\, vkp -.Decrypt Key(AuthMsg(p))|} vkca- 1 > 

new (n g :Public Challenge []); 

out k\ (CertVKq, res(getnonce(n q ))); 

inp w (p':Un, cipher:Un, fc 2 :Un); 

if p = p' then 

decrypt cipher is {|reg(pZam:(w:Un, a:Un, i:Un, </':Un, 

Public Response [end req(p,q' ,w,a,t)]))\^ vkp -i; 
match plain is (u>, rest:(a:Req(w), i:Un, g':Un, 

Public Response [end req(p, q', w, a, i)])); 
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split rest is (a:Req(w), 

t:(Jn, rest':(q':Un, Public Response [end req(p, q', w, a, t)])); 
match rest 1 is (q, n^:Public Response [end req(p, q, w, a, t)]); 
check n q is n' q ; 
end req(p, q, w, a, t); 
let r:Res(w)=ca\\ w (p, a); 
begin res(p,q,w,r,t); 

cast n p is (n':Public Response [end res(p,q,w,r,t)])\ 
out k 2 (q,{\res(w,r,t,p,n' p )\} SKq ) 
where q — owner{w) 

Finally, we need to change the top-level environment to account for the new keys, and to add a channel 
through which we will publish the public keys. 

Top-Level Environments: 

Edass i (c.£:Un) i^ClMetK 1 
E keys 4 DSCAiAuthCertKeys, (DSp:AuthKeys(p)) pePrm 

E ws = (w:Un) ^WebService 

E P rin =pi:Prin, . . . ,p„:Prin where Prin = {pi, . . . ,p n } 

Enet — net-Xin 

Eq E ws , Ep r i n , E ne t , E c i ass , Ek e y S 

Publishing can be achieved by simply sending the public keys on a public channel, here net: 
Public Keys Publishing: 

I net 4 out net ( VKCA, ( VKp) P^ p " n ) 

We can now establish that the resulting system is robustly safe: 
Theorem 2. If h a : A and p e Prin and k £ dom(E ) then the system 

new (E c i ass ,E keys )] (I net \ I dass \ I ws \ new (fc:Un); [a]£) 
is robustly safe. 

Proof. See Appendix D.2. □ 

The protocol we give above to provide authentication has some undesirable properties. Specifically, it 
requires the server to remember the certificate CertVKp and nonce n p at the time when a nonce is requested. 
Since anyone can request a nonce, and no authentication is performed at that stage of the protocol, this 
makes the server severely vulnerable to denial-of-service attacks. The following variation on the protocol 
achieves the same guarantees, but pushes the exchange of certificates and nonces to later messages, basically 
just when they are needed. 



p — > q on w : req(getnonceQ) , k\ 
q — > p on ki : res(getnonce(n q )) 

p -> q on w : p, CertVKp, n p ,§req(w,l{u\, . . . ,u n ),t,q, n q )\} S K Pl k 2 
q -> p on k 2 : q, CertVKq, §res(w,l{r),t,p,n p )§ S K q 



6.2. Authenticated and Encrypted Web Methods 

We now describe a protocol and implementation for authenticated and encrypted web methods. Hence, for 
now, we assume that all the exported methods of a web service are annotated with AuthEnc. 

The public- key infrastructure we consider for this case is similar to the one for authenticated web methods, 
except that now we have encryption and decryption keys, as opposed to signing and verification keys. Each 
principal p has an encryption key EKp and a decryption key DKp. The decryption key is kept private, while 
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the encryption key is public. To bind the name of a principal with their encryption key we again assume a 
certification authority CA (with a signing key SKCA and verification key VKCA) that can sign certificates 
CertEKp of the form {\p, EKp\}skca- 

Here is a protocol for p making a web service call w:£(ui, . . . , u n ) to service w owned by q, including the 
names of continuation channels used at the spi level. Again, we assume that in addition to the methods of 
class (w), each web service also supports a method getnonce, which we implement specially. 

p — > q on w : CertEKp, req(getnonceQ) , k\ 

q — > p on ki : CertEKq, Qmsggfa, nx )\;EKp, res{getnonce{n q )) 

p -> q on w : S\msg 3 (w,p, K,n K )\} EK q ,n p , {req(l(u\, . . . ,u n ),t,n q )} K , k 2 

g^ponfe : {res(£(r), t, n p )} K 

This protocol is similar to that for authenticated web methods, except that public key encryption is used to 
exchange a session-specific shared key K used to encrypt the actual method call. Specifically, in the third 
message, p chooses a session-specific shared key K, and sends it to q encrypted with g's public key EKq; this 
session key K is used to encrypt the web method call. The result of the web method call is also encrypted 
with this shared key. To prevent replay attacks, the shared key is bound to a nonce Hk sent by q in the 
second message. 



Type of Keys: 

SKey(p,q,w) = 

SharedKey(Union(reg(a:lln, i:lln, n g :Public Response [end req(p, q, w, a, t)]), 
res(r:Un, i:Un, n p :Public Response [end res(p,q,w,r,t)]))) 

AuthEncMsg(p) = 

Union(ms<7 2 (<z:Un, n^-:Private Challenge []), 
msg 3 (w:Un, g:Un, K :Top, 

nx:Private Response [trust K:SKey(p, q, w)])) 
AuthEncKeys(p) = KeyPair(AuthEncMsg(p)) 
AuthEncCert = (p:Un, Encrypt Key(AuthEncMsg(p))) 
AuthEncCertKeys = KeyPair(AuthEncCert) 



We will represent the key pair of an encryption key and decryption key for principal p by a pair PKp, 
of type AuthEncKeys(p). The signing key pair for the certification authority will be represented by a pair 
DSCA. We use the following abbreviations: 

Key and Certificates Abbreviations: 

i 1 

EKp = Encrypt (PKp) p's encryption key 

DKp = Decrypt [PKp) p's decryption key 

CertEKp = {\p, EKp\} skca p's certificate 

Again, we can amend the translation of Section 4 to accommodate the new protocol. First, we give a new 
translation for a web method call w:£(ui, . . . , u n ): 

New Translation of Web Method Call: 

\wAu u ...,u n )] p k ± ' 
new (fci:lln, fc 2 :Un, t:Un, n p :Public Challenge []); 
begin req(p,q,w, edmj, [u n ]),t); 
out w (CertEKp, req(getnonceQ), fci); 
inp k\ (c:Un, cipher:(Jn, res(getnonce(n q :Un))): 
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decrypt c is {\cert:(q':(Jn, Encrypt Key(AuthEncMsg((7 / )))|}y A - (;7yi -i; 
match cert is (q, eA;g:Encrypt Key(AuthEncMsg(g))); 
decrypt cipher is {|ms<?2(<7':Un, nx:Un)|} DA - p -i ; 
if q = q' then 

cast n q is (n' q :Pub\\c Response [end req(p, q, to, . . . , [u„]), t)]); 

new (^:SKey(p, q, to)); 
witness K:SKey(p, q, to); 

cast uk is (n' x :Private Response [trust K:SKey(p, q, to)]); 

out w ({|?7is ff3 (w;,p,i,i ; i:,n^)|} efcg ,np,{reg(w;,£([iii], . . . , [u„]), t, n' q )} K , fc 2 ); 

inp fc 2 (&<%:Un); 

decrypt &dt/ ' s {res(piam:(r:i2es(to), i':lln, 

Public Response [end res(p,q,w,r,t')]))} K ; 
match plain is (r:Res(w), rest:(t':Un, Public Response [end res(p, q, to, r, i')]))i 
match rest is (i, n p :Public Response [end res(p, q, to, r, i)]); 
check n p is rt p ; 
end res(p, g, to, r, t); 
case r is out fe a; 
where q = owner(w) 



We also need to give a new implementation for web services, again to take into account the different 
messages being exchanged: 

New Web Service Implementation: 

Iws (w) = 

repeat inp to (c:Un, bdy.Un, fci:lln); 
case bdy is req(getnonceQ); 

decrypt c is {|p:Un, efcp:Encrypt Key(AuthEncMsg(p))|} yA - (7yi -i; 
new (n g :Public Challenge []); 
new (n^iPrivate Challenge []); 

out k\ (CertEKq, {\msg2(q,riK)\iekp, res(getnonce(riq))); 
inp w (cipher i-Un, n p :lln, cipher ^.Dn, /c 2 :Un); 
decrypt cipher 1 

is {\msg 3 (plain 1 :(w:Un,p':Ur\, K.Top, 

Private Response [trust K:SKey(p' ,q,w)]))\} DKq -i; 
match plain 1 is (to, rest:(p':Un, K:Top, 

Private Response [trust K:5Key(p', q, w)])); 
match rest is (p, rest':(K:Top, Private Response [trust K:SKey(p, q, to)])); 
split rest' is (K :Top, n' K : Private Response [trust K:5Key(p, q, w)]); 
check riK is n' K ; 
trust K is (X':SKey(p, q,w))\ 
decrypt cipher 2 is {req(plain 2 :(a:Req(w),t:Un, 

Public Response [end req(p,q,w, a, t)]))}K r , 
split plain 2 is (a:Req(w), t:Un, n^Public Response [end reg(p, g, to, a, t)]); 
check n«j is n' q ; 
end req(p, q, to, a, i); 
let r:i?es(to)=call^(p, a); 
begin res(p,q,w,r,t); 

cast rip is (n p :Public Response [end res(p, q, to, r, t)]); 
out k 2 {res(r,t,n' p )} K > 
where q = owner(w) 



Finally, we need to change the top-level environment to account for the new keys, and to add a channel 
through which we will publish the public keys. 
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Top-Level Environments: 




where Prin — {pi, . . . ,p n } 



Publishing can be achieved by simply sending the public keys on a public channel, here net: 
Public Keys Publishing: 

I net 4 out net (VKCA, (EKp) P£ p ™) 



We can now establish that the resulting system is robustly safe: 
Theorem 3. If h a : A and p G Prin and k £ dom(Eo) then the system 

new {E class ,E keys ); (I net \ I class \ I ws | new (fc:Un); [a]£) 
is robustly safe. 

Proof. See Appendix D.3. □ 
We can note some further possibilities, with respect to the protocols implemented in this section: 

• The protocol implementing authenticated and encrypted invocation uses certificates to essentially nego- 
tiate a symmetric key with which to actually perform the encryption. It is straightforward to apply the 
same idea to the authenticated-only case, negotiating a symmetric key with which to hash the content 
of the method call (instead of relying on public-key signatures). 

• In the above protocol, a new symmetric key is negotiated at every method invocation. A more efficient 
variation would be to re-use a negotiated symmetric key over multiple web method calls. Once a symmetric 
key has been negotiated, it can effectively act as a shared key between the two principals, which is the 
case we investigated in the body of this paper. We can therefore use the above protocol for the first web 
method call between a principal and a particular service, and the shared-key protocol for subsequent web 
method calls. 



There has been work for almost twenty years on secure RPC mechanisms, going back to Birrcll [10]. More 
recently, secure RPC has been studied in the context of distributed object systems. As we mentioned, our 
work was inspired by the work of van Doom et at [35], itself inspired by [30, 36]. These techniques (or similar 
ones) have been applied to CORBA [31], DCOM [11], and Java [7, 19]. 

In contrast, little work seems to have been done on formalizing secure RPC. Of note is the work of Abadi, 
Fournet, and Gonthier [2, 3], who show how to compile the standard join-calculus into the sjoin-calculus, and 
show that the compilation is fully abstract. In a subsequent paper [4], they treat similarly and more simply 
a join-calculus with authentication primitives: each message contains its source address, there is a way to 
extract the principal owning a channel from the channel, and any piece of code runs as a particular principal. 
Their fully abstract translation gives very strong guarantees: it shows that for all intents and purposes, we 
can reason at the highest level (at the level of the authentication calculus). Although our guarantees are 
weaker, they are easier to establish. 

Duggan [18] formalizes an application-level security abstraction by introducing types for signed and 
encrypted messages; he presents a fully abstract semantics for the abstraction by translation to a spi-calculus. 

Much of the literature on security in distributed systems studies the question of access control. Intuitively, 
access control is the process of determining if the principal calling a particular method has permission to 
access the objects that the method refers to, according to a particular access control policy. There is a 
distinction to be made between authentication and access control. Authentication determines whether the 
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principal calling a method is indeed the principal claiming to be calling the method, while access control can 
use this authenticated identity to determine whether that principal is allowed access. This distinction is made 
clear in the work of Balfanz et al. [7] , where they provide authenticated and encrypted communication over 
Java RMI (using SSL) and use that infrastructure as a basis for a logic-based access control mechanism. The 
access control decisions are based on the authenticated caller identity obtained from the layer in charge of 
authentication. This approach is also possible in our framework, which provides access to an authenticated 
identity as well. We plan to study access control abstractions in our framework. Various forms of access 
control mechanisms have been formalized via 7r-calculi, [26, 33, 27], and other process calculi [13, 16]. An 
access control language based on temporal logic has been defined by Sirer and Wang [34] specifically for web 
services. Damiani et al. [15] describe an implementation of an access control model for SOAP; unlike our 
work, and the WS-Security proposal, it relics on an underlying secure channel, such as an SSL connection. 

Since this work was completed, a series of specifications for web services security has been published, as 
laid out in a whitepaper from IBM and Microsoft [28]. In particular, WS-Security [6] defines how to add 
signatures, to apply encryption, and to add principal identities, such as usernames or certificates, to a SOAP 
envelope. It would be straightforward, for example, to adapt our implementation to produce WS-Security 
compliant SOAP envelopes. A recent paper shows how to formalize the authentication goals of protocols 
based on WS-Security using the applied 7r-calculus [9]. 

Despite its enjoyable properties, the formal model we use to study the implementation of our security 
abstraction suffers from some limitations. For instance, it makes the usual Dolev-Yao assumptions that 
the adversary can compose messages, replay them, or decipher them if it knows the right key, but cannot 
otherwise "crack" encrypted messages. A more severe restriction is that we cannot yet model insider attacks: 
principals with shared keys are assumed well-behaved. Work is in progress to extend the Cryptyc type theory 
to account for malicious insiders. We have not verified the hash-based protocol of Section 2. 

8. Conclusions 

Authenticated method calls offer a convenient abstraction for developers of both client and server code. 
Various authorisation mechanisms may be layered on top of this abstraction. This paper proposes such an 
abstraction for web services, presents a theoretical model, and describes an implementation using SOAP-level 
security. By typing our formal semantics, we show no vulnerability exists to attacks representable within the 
spi-calculus, given certain assumptions. Vulnerabilities may exist outside our model — there are no methods, 
formal or otherwise, to guarantee security absolutely. 

While our approach is restricted to proving properties of protocols that can be established using the 
Cryptyc type and effect system, it is worth pointing out that it is compatible with alternative methods 
for protocol verification. For instance, it is possible to analyze the protocols we use to implement secure 
web method calls for security flaws beyond those that can be uncovered using Cryptyc (for instance, flaws 
involving malicious insiders). 

Our work shows that by exploiting recent advances in authenticity types, we can develop a theoretical 
model of a security abstraction, and then almost immediately obtain precise guarantees. (As with many 
formal analyses, these guarantees concern the design of our abstraction, and do not rule out code defects in 
its actual implementation.) 

This study furthermore validates the adequacy of the spi-calculus, and Cryptyc in particular, to formally 
reason about security properties in a distributed communication setting. 

Acknowledgments Cryptyc is an ongoing collaboration between Alan Jeffrey and the first author. Ernie 
Cohen, Cedric Fournet, and Alan Jeffrey made useful suggestions during the writing of this paper. 

A. Sample SOAP Messages 

We give some sample SOAP messages exchanged during web service method calls of the web service described 
in Section 5. One thing that is immediately clear is that we are not using standard XML formats for signing 
and encrypting messages, such as XML-Encryption and XML-Signature. There is no intrinsic difficulty 
in adapting our infrastructure to use standard formats. The point is that the validation of the security 
abstraction does not rely on the exact syntax of the SOAP envelopes. 
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A.l. An Authenticated Call 

We describe an authenticated call to the Balance method. The messages exchanged to obtained the nonce 
are standard SOAP messages. The following message is the request from Alice to the web service to execute 
the Balance method on argument 12345. Notice the DSHeader element holding the identity of the principals 
involved, as well as the nonces and the cryptographic signature. 

<?xml version="1.0" encoding="utf-8"?> 

<soap : Envelope xmlns : soap="http : // schemas .xmlsoap . org/soap/envelope/" 
xmlns : xsi="http : //www . w3 . org/2001/XMLSchema- instance" 
xmlns : xsd="http : //www . w3 . org/200 l/XMLSchema"> 

<soap :Header> 

<DSHeader xmlns="http : //tempuri . org/"> 
<callerid>Alice</callerid> 
<calleeid>Bob</calleeid> 
<np>13</np> 
<nq>42</nq> 
<signature> 

3E:67:75:28:3B:AD:DF:32:E7:6C:D3:66:2A:CF:E7:8A:3F:0A:A6:0D 
</signature> 
</DSHeader> 
</soap :Header> 
<soap :Body> 

<Balance xmlns="http : //tempuri . org/"> 

<account>12345</account> 
</Balance> 
</soap :Body> 
</soap : Envelope> 

The response from the web service has a similar form: 
<?xml version="1.0" encoding="utf-8"?> 

<soap : Envelope xmlns : soap="http : //schemas . xmlsoap . org/soap/envelope/" 
xmlns : xsi="http : //www . w3 . org/200 1/XMLSchema- instance" 
xmlns : xsd="http : //www . w3 . org/2001/XMLSchema"> 

<soap :Header> 

<DSHeader xmlns="http : //tempuri . org/"> 
<callerid>Alice</callerid> 
<calleeid>Bob</calleeid> 
<np>13</np> 
<nq>42</nq> 
<signature> 

8D:31:52:6E:08:F0:89:7B:1E:12:3F:5E:63:EE:B0:D2:63:89:CA:73 
</signature> 
</DSHeader> 
</soap :Header> 
<soap :Body> 

<BalanceResponse xmlns="http : //tempuri . org/"> 

<BalanceResult>100</BalanceResult> 
</BalanceResponse> 
</soap:Body> 
</soap : Envelope> 

A. 2. Authenticated and Encrypted Call 



We describe an authenticated and encrypted call, this time to the Statement method. Again, the messages 
exchanged to obtained the nonce are standard SOAP messages. The following message is the request from 
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Alice to the web service to execute the Statement method on argument 12345. As in the authenticated call 
above, the DSHeader element holds identity information. The body of the message itself is encrypted. Note 
that the nonce nq must be encrypted according to the protocol, so its encrypted value is included in the 
encrypted data, and its element is reset to a dummy value (here, -1). Similarly the signature is unused and 
set to a dummy value. 

<?xml version="1.0" encoding="utf-8"?> 

<soap : Envelope xmlns : soap="http : //schemas .xmlsoap . org/ soap/envelope/" 
xmlns : xsi="http : //www . w3 . org/200 1/XMLSchema- instance" 
xmlns : xsd="http : //www . w3 . org/2001/XMLSchema"> 

<soap :Header> 

<DSHeader xmlns="http : //tempuri . org/"> 
<callerid>Alice</ callerid> 
<calleeid>Bob</calleeid> 
<np>13</np> 
<nq>-K/nq> 

<signature>4E : 00 : 6F : 00</signature> 
</DSHeader> 
</soap :Header> 
<soap :Body> 
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</soap :Body> 
</soap : Envelope> 

The response is similarly encoded. Notice that this time the nonce np must be encrypted, so its value is 
again included in the encrypted data, and its element is reset to a dummy value. 

<?xml version=" 1 . 0" encoding="utf-8"?> 

<soap : Envelope xmlns : soap="http : //schemas .xmlsoap . org/soap/ envelope/" 
xmlns : xsi="http : //www . w3 . org/2001/XMLSchema- instance" 
xmlns : xsd="http : //www . w3 . org/2001/XMLSchema"> 

<soap :Header> 

<DSHeader xmlns="http : //tempuri . org/"> 
<callerid>Alice</ callerid> 
<calleeid>Bob</calleeid> 
<np>-K/np> 
<nq>-K/nq> 

<signature>4E : 00 : 6F : 00</signature> 
</DSHeader> 
</ soap : Header> 
<soap :Body> 
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0A:64:ED:F3:9C:18:94:EC:4F:CF:61:92:38:EF:A9:46:E8:4E:E9: 
4A : E6 : 8A : C9 : 5E : ED : A7 : 34 : 72 : 3E : 72 : A2 : BE : OD : DC : 07 : 22 : 45 : BO : 
E6 : 79 : 33 : 8F : CD : 90 : B8 : 97 : DB : BA : 3B : B2 : 8B : 38 : 38 : B6 : 5B : Fl : 1 1 : 
FB:DD:88:CE:9A:3E:B4:E6:31:13:CB:1C:F3:B5:17:D8:9B:CF:2E: 
65:23:4D:BA:ED:72:6D:F4:53:97:B8:7A:D2:9C:2C:10:58:A3:0E: 
FE:48:A2:2A:2A:57:AE:6D:69:4D:97:90:EF:9F:C6:7E:9B 
</soap:Body> 
</soap : Envelope> 

B. Semantics of the Object Calculus 

In this appendix, we give a formal description of the operational semantics and typing rules of the object 
calculus. We first describe some encodings showing the expressiveness of the calculus. 

B.l. Encoding Arithmetic 

The calculus is simple enough that questions about whether or not it is sufficiently expressive to be of interest 
arise. This is especially likely since there are no recursive functions in the calculus, and it is not clear that 
it is even Turing complete. That the calculus indeed is Turing complete is a consequence of the fact that we 
can write recursive classes and methods, and that we have a null object. The following example shows an 
encoding of natural numbers as a class Num, with the typical recursive definition of addition: 

class Num 
Num pred 
Num succQ 

new Num{this) 
Num add(Numx) 

if x.pred = null then 
this 

else this. add(x. pred). succQ 
We define zero as new Num(null), one as zero.succ(), and so on. 

B.2. Formalization of proxy objects 

We mentioned in the text that we can easily express proxy objects within the calculus. For completeness, 
here is a detailed formalization of such proxy objects. First, we assume a map proxy G WebService — > Class, 
assigning to every web service w € WebService a proxy class proxy(w). We further assume that for each 
w G WebService, 

• dom (methods (class (w))) U {Id} = dom (methods (proxy (w))), 

• fields (proxy (w)) = 0, 

• methods (proxy (w) (Id)) = (IdQ, owner (w)), and 

• for all I G dom(methods (class (w))), 

methods (proxy (w)) (I) — (B(Ai x\, . . . , A n x n ), wl(x\, . . . , x n )), 
where methods (class (w)) (£) = (B(Ai x\,...,A n x n ),b). 

B.3. Operational Semantics 

The operational semantics is defined by a transition relation, written a a' , where a and a' are method 
bodies, and p is the principal evaluating the body a. 

To specify the semantics, we need to keep track of which principal is currently running a method body. 
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We add a new method body form to our object calculus, p[a], meaning p running body a. This form does 
not appear in code written by the user, but only arises through the transitions of the semantics. 

Extended Method Bodies: 



a, b G Body ::= 


method body 

as in Section 3 


p[a] 


body a running as p 


Transitions: 


(Red Let 1) (Red Let 2) 
a a' 


let x—a in b -^ p let x=a! in b let x=v in 


b -> p b{x^v} 


(Red If) 




if u = v then a true else af a i se — > p a u=v 




(Red Field) 

fields{c) = ft* V el " n jel..n 




(new c(vi, . . .,v n )).fj -^ p Vj 




(Red Invoke) (where v = new c(v\, . . . , v n )) 
methods(c) = £ i \-^> (sig i ,b i ) iel -- n j £ \.. n 


sig-j = B(A X xi,...,A m x m ) 


v.£j(u\, . . . ,u m ) ~^ p bj{this^v, 


x k ^u k fee1 -™} 


(Red Remote) 

owner (w) = q class (w) = c 




w:£(ui, . . .,u n ) —> p q[new c(p).£(ui, . . . ,u n )] 





(Red Prin 1) (Red Prin 2) 
a a' 

q[a] -^ p q[a'} q[v] ^ p v 



B.4. Type System 



The judgments of our type system all depend on an environment E, that defines the types of all variables 
in scope. An environment takes the form x\\A\, . . . , x n :A n and defines the type Ai for each variable x^. The 
domain dom(E) of an environment E is the set of variables whose types it defines. 

Environments: 



D,E::= 



E,x:A 
dom(xi:Ai, 



environment 
empty 
entry 

domain of an environment 



The following are the two judgments of our type system. They are inductively defined by rules presented 
in the following tables. 

Judgments E h J: 



E h a : A 



good environment 

good expression a of type A 
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We write E b J when we want to talk about both kinds of judgments, where J stands for either o or a : A. 
The following rules define an environment x\\Ai, . . . , x n :A n to be well- formed if each of the names 
distinct. 

Rules for Environments: 

(Env 0) (Env x) (where x £ dom(E)) 

b o E, x:A b o 

We present the rules for deriving the judgment E b a : A that assigns a type A to a value or method 
body a. These rules are split into two tables, one for values, and one for method bodies. 

Rules for Typing Values: 



(Val x) (Val null) 

E = E 1 ,x:A,E 2 Eho Eho 



E b x : A Eh- null : c 

(Val Object) (Val Princ) 

fields (c) = Si ^ A, iel - n EY- Vj : Aj Vj g l..n £ho 

E b new c(vi, . . . , v n ) : c E h p : Id 



Rules for Typing Method Bodies: 



(Body Let) 

E\-a:A E,x:A\~b:B 
E b Zei x—a in b : B 

(Body If) 

E \- u : A E \- v : A E b a : g E \- b : B 
E \- if u = v then a else b : B 

(Body Field) 

ghi):c fields jc) = ^j-> A, jgl..n 

(Body Invoke) 
£h»:c methods(c) = £i >-> (sig i: h) iel - n j g l..n 
szff 7 - = i3(Ai xi , . . . , ^4 m x m ) E h Uk ■ Ak Vfc 6 l..rw 

_B h vl {ui, . . .,u m ) : B 

(Body Remote) , . 

class(w) = c methods(c) = £ i <— ► (sig i ,bi) iel - n j g l..n ^ (- a • A 
sip.- = xi, . . . , /L„ x m ) E \- Ui : Ai Vi G l..m 



£ b w:£j(ui, . . . ,u m ) : B 



E b p[o] : i4 



We make the following assumption on the execution environment. 
Assumptions on the Execution Environment: 



(1) For each w g WebService, fields (class (w)) = Callerld : Id. 

(2) No tagged expression p[a] occurs within the body of any method; 

such expressions occur only at runtime, to track the call stack of principals. 

(3) for each c g Class and each £ g dom (methods (c)) , 
if methods (c)(£) = (B(A\ x\, . . . , A n x n ),b), 
then this:c, x\:Ai, . . . , x n :A n b b : B. 
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It is straightforward to show that our type system is sound, that is, that the type system ensures that 
methods that typecheck do not get stuck when evaluating. Some care is needed to make this precise, since 
evaluation can block if one attempts to access a field of a null object, or to invoke a method on a null object. 
(We could introduce an error token in the semantics and propagate that error token when such a case is 
encountered, but this would needlessly complicate the semantics, at least for our purposes.) Soundness can 
be derived as usual via Preservation and Progress theorems. To establish these, we first need the following 
lemmas: 

Lemma 1. The following properties of judgments hold: 

(Exchange) if E, x:A, y.B, E' b J, then E, y.B, x:A, E' b J; 
(Weakening) if E b J and x $ dom(E), then E, x:A b J; 
(Strengthening) if E, x:B \- a : A and x $ fv(a), then E b a : A. 

Proof. Straightforward. □ 

We often use the above properties silently in the course of proofs. 

Lemma 2 (Substitution). If E, x:B b a : A and E b v : B, then E b a{x^v] : A 

Proof This is a straightforward proof by induction on the height of the typing derivation for E b a : A. 
We proceed by case analysis on the form of a. 

- Case a = x: Since E, x:B b x : A, we must have A — B. Since a{x^v} = v and E b v : B, we have 
E b v : A, as required. 

- Case a — y, where y ^ x: Since x is not free in y, E, x:B b y : A implies E b y : A, by the Strengthening 
Lemma, as required. 

- Case a = null: Since x is not free in null, E, x:B b null : A implies E b null : A, as required. 

- Case a — p: Since x is not free in p, E, x:B b p : A implies E b p : A, as required. 

- Case a = newc(v\, . . . , v n ): We have the equation newc(v\, . . . , v n ){x^v} = newc(vi{x-<—v}, . . . , v n {x^v}). 
We have E,x:B b new c(ui,...,u„) : A, hence E,x:B b : Ai if fields(c) = ft ^4^ »€i..n_ g y 
the induction hypothesis, we know E b Vi{x^v} : Ai for all i G l..n. Hence, we can derive E b 
new c(i; 1 {a;^i;}, . . . , w„{a;^i;}) : A, as required. 

- Case a — let y=ao in b: Without loss of generality, we can take y ^ x, since y is bound in b. Note 
that (let y=ao in b){x^v} = let y=a>o{x^v} in b{x^v}. We have E,x:B b let y=a,Q in b : A, hence 
E,x:B b a : A for some A , and E,y:A ,x:B b b : A. By the induction hypothesis, E b a {x^v} : A 
and E, y:A b b{x^v} : A, and hence E b let x=a {x^v} in b{x^v} : A, as required. 

- Case a = if u = ui then a else a\: We have (if u = ui then a else cii){x+~v} = if u {x^v} = 
U\{x*— v} then o,q{x^v} else a>i{x^~ v}. We have E,x:B b if Uq = U\ then a else a\, hence E,x:B b 
u : A', E,x:B b u\ : A', E,x:B b a : A and E,x:B b a\ : A. Applying the induction hypothesis to 
these judgments, we can derive 

E b if u {x^v} = ui{x^v} then a {x^v} else a\{x^v} : A 

as required. 

The remaining cases are similar, upon noting that: 

- (u.fj){x^v} = u{x^v}.fj, 

- (ul(u\, . . ., u m )){x^v} = u{x^v}(ui{x^v}, . . . , u m {x^v}), 

- (w:l(u\, . . . , u n )){x^v} = w:(ui{x^v }, . . . , u n {x^v }), and 

- (p[a]){x<—v}=p[a{x<—v}]. □ 
Theorem 4 (Preservation). If E b a : A and a a 1 then E b a' : A. 

Proof We proceed by induction on the height of the typing derivation for E b a : A. Since a a', a 
cannot be a value v. 

- Case a = let x=v in b: Since E b a : A, we have E b v : B and E, x:B b b : A. We must have 
a 1 = b{x^v}. Applying the Substitution Lemma, we have E b b{x^v} : A, as required. 
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- Case a = let x=ao in b, where cio is not a value: We have E h ao : B, and E, x:B \- b : A. Since a —> p a', 
we must have have ao a 'o- By induction hypothesis, E h a' : B, and hence E h Zet x=a in b : A, as 
required. 

- Case a= if u = v then a else a\: Note that either a -^ p a or a -^ p a\. In both cases, since E h if u = 
v then a else a\ : A, we have E h a : A and E \- cii : A, as required. 

- Case a = (newc(vi, . . . ,v n )).fj: We have fields (c) = fi i— > yV el The type derivation for a is as follows: 

£hi)i : A t iel - n 
E h new c(«i, . . . , v n ) : c 
E h (new c(vi, . . . , v n )).fj ■ A 

Since a' = vj, we have E h required. 

- Case a — (new c(v\, . . . , v n ))-£j (wi, ■ ■ ■ , u m ): Let v = new c(vi, . . . , v n ). We have methods(c) = i-» 
(sig i ,b i ) * el -- n 5 where sig.,- = -B(Ai £1, . . . , -A m x r „). By the typing derivation for h a : £?, we have 
E \- Uk : Ak for all fc <G l..m, and £ h ti : c. By assumption on the execution environment, we know 
this:c,xi:Ai, . . . ,x m :A m h b : B. Applying the Substitution and the Weakening Lemmas, we get E h 
b{this^v,Xk^Uk fcel - m } : B, as required. 

- Case a — w:£j(u\, . . . , u n ): We have class(w) — c, methods(c) = li i— > (sig i ,b i ) tel - n where si<7 ■ = 

xi, . . . , A m x m ). By the typing derivation for E h a : £?, we have E h Ui : Ai for all i 6 l..m. We 
can therefore derive the required type for a' = q[new c(p).£(u\, . . . , u m )\: 

E h new c(p) : c E h Uj : Ai Mi e l..m 
£7 h new c(p).£(ui, . . . , w m ) : B 
E h g[new c(p).£(ui, . . . , u m )\ : B 

- Case a = q[v]: Since E h g[v] : A, we have £ h w : i, and o[u] u, as required. 

- Case a — q[ao], where ao is not a value: Since E h g[ao] : A, we have £ h o : i, and since a — > p a', we 
must have a a . By induction hypothesis, E \- a' : A, and hence E h g[a ] : A, as required. □ 

To state the Progress Theorem, we need to recognize programs that are blocked because of a null in 
object position. We say a method body a is null-blocked if, essentially, it is stuck trying to access a field of 
a null object, or invoke a method on a null object. Formally, a is null-blocked if it is of the form null.fj, 
null.£(ui, . . . ,u n ), let x=a in b (where a is null-blocked), or q[a] (where a is null-blocked). 

Theorem 5 (Progress). If h a : A and a is not a value and is not null-blocked, and p £ Prin, then 
a a 1 for some a'. 

Proof Again, we proceed by induction on the height of the typing derivation for h a : A. We assume a 
is not a value, and a is not null-blocked. 

- Case a = let x=a in b: We consider two subcases, depending on whether a is a value or not. 

- Case ao is a value v: We have a — > p b{x^v}. 

- Case a is not a value: Since h a : A, we have \- a : B for some J5, ao not a value. Since a is 
not null-blocked, ao is not null-blocked. Hence, by induction hypothesis, we have ao a' . Hence, 
we have a -^ p let x—a' in b. 

- Case a = if u = v then a else a\: We have a ~^> p a or a -^> p a\ depending on the result of u = v. 

- Case a = v.fj: Since h a : A and a is not null-blocked, we must have v = new c(u\, . . . ,u n ), and 
fields(c) = fi i ^ Ai * el --™. Therefore, we have v.fj -^> p uj. 

- Case a = v.£j(ui, . . . , u m ): Since h a : A and a is not null-blocked, we must have v = newc(u\, . . . , «„), 
methods(c) = £ j i— > (sif^, 6j), and sig^- = B(Ai xi, . . . , A m x m ). Therefore, we have v.£j(u\, . . . , u m ) -^ p 
bj{this<^v,Xk<—Uk feel - m }. 

- Case a = w:£(ui, . . . , u m ): The following transition rule w:£(ui, . . . , u m ) ^ p q[new c(p).£(u\, . . . , w m )] 
applies, with owner(w) = q and class(w) = c. 

- Case a = g[a ]: We consider two subcases, depending on whether a is a value or not. 
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- Case oo is a value v: We have q[v] —+ p v. 

- Case ao is not a value: Since h q[ao] : A, we have h ao : A, ao not a value. Since a is not null- 
blocked, a is not null-blocked. Hence, by induction hypothesis, we have do ^ q a' , and q[a ] q[a' ]. 

□ 

We can now state soundness formally. We say a method body a is stuck if a is not a value, a is not 
null-blocked, and there is no a' and p such that a — > p a'. We write a — >* a' to mean that there exists a 
sequence ai, . . . , a n and principals pi, . . . ,p n +i such that a -^ Pl a\ -^ P2 ■ ■ ■ -^ Pn a n -^ p ™+ 1 a'. (Hence, — >* is 
a kind of transitive closure of -^ p .) 

Theorem 6 (Soundness). If h a : A, and a — ►* a' , then a' is not stuck. 

Proof. A straightforward induction on the number of transitions in a a'. □ 



C. The Spi-Calculus in More Detail 



We give an overview of the language and type system on which our analysis of web services depends. We give 
the syntax in detail, but for the sake of brevity give only an informal account of the operational semantics 
and type system. Full details are in a technical report [21], from which some of the following explanations 
are drawn. Some constructs primitive here are actually derived forms in the original calculus. 

Names, Messages: 



k ::= Encrypt 

to, n, x, y, z 
L, M, N ::= 
x 

(Mi,... 
U{M) 
{M} N 

{\M\} N 
k (M) 



Decrypt 



key attribute 

name: nonce, key, key-pair 
message 
name 

record, n > 
tagged union 
symmetric encryption 
asymmetric encryption 
key-pair component 



The message a; is a name, representing a channel, nonce, symmetric key, or asymmetric key-pair. We do 
not differentiate in the syntax or operational semantics between key-pairs used for public key cryptography 
and those used for digital signatures. 

The message (Mi, . . . , M n ) is a record with n fields, Mi, . . . , M n . 

The message U{M) is message M tagged with tag t,. The message {M}n is the ciphertext obtained by 
encrypting the plaintext M with the symmetric key N. 

The message {|M|}at is the ciphertext obtained by encrypting the plaintext M with the asymmetric 
encryption key N. 

The message Decrypt (M) is the decryption key (or signing key) component of the key-pair M, and 
Encrypt (M) is the encryption key (or verification key) component of the key-pair M. 

Types and Effects: 



I ::= Public | Private 

S,T,U::= 
Un 

{x\ \T\ , . . . , x n '.Tji) 

Union(ti(Ti),...,t„(r n )) 

Top 

SharedKey(T) 
KeyPair(T) 
k Key(T) 
I Challenge es 
I Response fs 
e,f:~ 



nonce attribute 
type 

data known to the opponent 
dependent record, n > 
tagged union 
top 

shared-key type 
asymmetric key-pair 
encryption or decryption part 
challenge type 
response type 
atomic effect 
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end L 



end-event labelled L 
name-check for a nonce N 
trust that M:T 



check I N 
trust M:T 



es,fs ::= 

[c± , . . . , 6 n 



effect 



multiset of atomic effects 



The type Un describes messages that may flow to or from the opponent, which we model as an arbitrary 
process of the calculus. We say that a type is public if messages of the type may flow to the opponent. Dually, 
we say a type is tainted if messages from the opponent may flow into the type. The type Un is both public 
and tainted. 

The type (x\:Ti, . . . , x n :T n ) describes a record (M\, . . . ,M n ) where each Mi : Ti. The scope of each 
variable Xi consists of the types T i+ i, . . . , T n . Type {xf.Ti, . . . , x n :T n ) is public just if all of the types Ti are 
public, and tainted just if all of the types Ti are tainted. 

The type Union(t 1 (T 1 ), . . . ,t n (T n )) describes a tagged message ti(M) where i E l..n and M : Ti. Type 
Union(ti(Ti), . . . , t n (T n )) is public just if all of the types Ti are public, and tainted just if all of the types 
T are tainted. 

The type Top describes all well-typed messages; it is tainted but not public. 

The type SharedKey(T) describes symmetric keys for encrypting messages of type T; it is public or tainted 
just if T is both public and tainted. 

The type KeyPair(T) describes asymmetric key-pairs for encrypting or signing messages of type T; it is 
public or tainted just if T is both public and tainted. The key-pair can be used for public-key cryptography 
just if T is tainted, and for digital signatures just if T is public. 

The type Encrypt Key(T) describes an encryption or signing key for messages of type T; it is public just 
if T is tainted, and it is tainted just if T is public. 

The type Decrypt Key(T) describes a decryption or verification key for messages of type T; it is public 
just if T is public, and it is tainted just if T it tainted. 

The types I Challenge es and t Response fs describe nonce challenges and responses, respectively. The 
effects es and fs embedded in these types represent certain events. An outgoing challenge of some type 
t Challenge es can be cast into a response of type t Response fs and then returned, provided the events in 
the effect es + fs have been justified, as explained below. Therefore, if we have created a fresh challenge at 
type I Challenge es, and check that it equals an incoming response of type I Response fs, we can conclude 
that the events in es + fs may safely be performed. The attribute t is either Public or Private; the former 
means the nonce may eventually be public, while the latter means the nonce is never made public. Type 
Public Challenge es is public, or tainted, just if es = []. Type Public Response fs is always public, but tainted 
just if es = []. Neither Private Challenge es nor Private Response fs is public; both are tainted. 

An effect es is a multiset, that is, an unordered list of atomic effects, e or /. Effects embedded in challenge 
or response types signify that certain actions are justified, that is, may safely be performed. An atomic effect 
end L justifies a single subsequent end-event labelled L, and is justified by a distinct, preceding begin-event 
labelled L. An atomic effect check I N justifies a single subsequent check that an I response equals an t 
challenge named N, where I is Public or Private, and is justified by freshly creating the challenge N. An 
atomic effect trust M:T justifies casting message M to type T, and is justified by showing that M indeed 
has type T. 



Processes: 



0,P,Q,R::= 



out M N 

inp M (x:T);P 

repeat inp M (x:T);P 

split M is (x 1 :T 1 ,...,x n :T n );P 

match M is (N,y:T);P 

case M is t t { Xl :Ti); P t i€l - n 

if M = N then P else Q 

new (x:T);P 

P\Q 



process 



stop 



output 

input (x bound in P) 

replicated input (x bound in P) 

record splitting 

pair matching (y bound in P) 

tagged union case (tj distinct) 

conditional (new) 

name generation (x bound in P) 

composition 

inactivity 
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decrypt M is {x:T} N ;P 
decrypt M is {\x:T\} N -i;P 
check M is N;P 
begin L; P 
end L;P 

cast M is (ar:T);P 
witness M:T; P 
trust M is (x:T);P 



symmetric decrypt (x bound in P) 

asymmetric decrypt (x bound in P) 

nonce-checking 

begin-assertion 

end-assertion 

cast to nonce type 

witness testimony 

trusted cast 



The processes out M N and inp M (x:T);P are output and input, respectively, along an asynchronous, 
unordered channel M. If an output out x N runs in parallel with an input inp x (y); P, the two can interact 
to leave the residual process P{y^N} 7 the outcome of substituting N for each free occurrence of y in P. 
We write out x (M);P as a simple shorthand for out x M \ P. 

The process repeat inp M (x:T);P is replicated input, which behaves like input, except that each time an 
input of N is performed, the residual process P{y^~N} is spawned off to run concurrently with the original 
process repeat inp M (x:T);P. 

The process split M is (x\:Ti, . . . , x n :T n );P splits the record M into its n components. If M is (Mi, . . . , M„), 
the process behaves as P{:ri^Mi} • • • {i„<-M„}. Otherwise, it deadlocks, that is, does nothing. 

The process match M is (N, y:U); P splits the pair (binary record) M into its two components, and checks 
that the first one is N. If M is (N,L), the process behaves as P{y^L}. Otherwise, it deadlocks. 

The process case M is ti(xf.Ti); Pi " checks the tagged union M. If M is tj(L) for some j G l..n, the 
process behaves as P{xi^- L}. Otherwise, it deadlocks. 

The process if M = N then P else Q behaves as P if M and N are the same message, and otherwise as 
Q. (This process is not present in the original calculus [21] but is a trivial and useful addition.) 

The process new (x:T); P generates a new name x, whose scope is P, and then runs P. This abstractly 
represents nonce or key generation. 

The process P \ Q runs processes P and Q in parallel. 

The process stop is deadlocked. 

The process decrypt M is {x:T}n;P decrypts M using symmetric key N. If M is {L}n, the process 
behaves as P{x^L}. Otherwise, it deadlocks. We assume there is enough redundancy in the representation 
of ciphertexts to detect decryption failures. 

The process decrypt M is Qx:Tfy N -i;P decrypts M using asymmetric key N. If M is {|£|}Encrypt (K) an d 
N is Decrypt (K), then the process behaves as P{x^L}. Otherwise, it deadlocks. 

The process check M is N ; P checks the messages M and N are the same name before executing P. If 
the equality test fails, the process deadlocks. 

The process begin L; P autonomously performs a begin-event labelled L, and then behaves as P. 

The process end L; P autonomously performs an end-event labelled L, and then behaves as P. 

The process cast M is (x:T); P binds the message M to the variable x of type T, and then runs P. In 
well-typed programs, M is a challenge of type I Challenge es, and T is a response type I Challenge fs. This 
is the only way to populate a response type. 

The process witness M:T; P simply runs P, but is well-typed only if M has the type T. This is the only 
way to justify a trust M:T effect. 

The process trust M is (x:T); P binds the message M to the variable x of type T, and then runs P. In 
well-typed programs, this cast is justified by a previous run of a witness M:T; Q process. 

Next, we recall the notions of process safety, opponents, and robust safety introduced in Section 4. The 
notion of a run of a process can be formalized by an operational semantics. 

Safety: 

A process P is safe if and only if 

for every run of the process and for every L, 

there is a distinct begin L event for every end L event. 



Opponents and Robust Safety: 

A process P is assertion-free if and only if 
it contains no begin- or end-assertions. 
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A process P is untyped if and only if 

the only type occurring in P is Un. 
An opponent O is an assertion-free untyped process. 
A process P is robustly safe if and only if 

P | O is safe for every opponent O. 



Our problem, then, is to show that processes representing protocols are robustly safe. We appeal to a 
type and effect system to establish robust safety (but not to define it). The system involves the following 
type judgments. 

Judgments E h J: 

£ho good environment 

E h es good effect es 

EVP good type T 

EV- M :T good message M of type T 

E h P : es good process P with effect es 



We omit the rules defining these judgments, which can be found in [21]; our previous informal explanation 
of types should give some intuitions. 

We made two additions to the language as defined in [21], namely the empty record type () (and corre- 
sponding empty record message ()), and the conditional form if M = N then P else Q. The empty record type 
can be handled by simply extending the typing rules for records to the case where there are no elements. The 
main consequence of this is that the type () will be isomorphic to the type Un, by the extended subtyping 
rules. The extension of spi to handle the conditional is similarly straightforward, except that we need to 
actually add a transition rule to the operational semantics, and a new typing rule to propagate the effects. 
For completeness, we describe the additions here, with the understanding that they rely on terminology 
defined and explained in [21]: 



Extensions to Spi for the Conditional: 



[if M 


= N then P true else Pf a Ue] + As 


-> [Pm=n] + As 


transition rule 


(Proc 


If) 






E h 


M : Top E h TV : Top EVP: 


es EhQ:fs 


typing rule 




£ h if M = N then P else Q 


-.esVfs 



The type and effect system can guarantee the robust safety of a process, according to the following 
theorem [21]: 

Theorem 7 (Robust Safety). If xi:\Jn, . . . , x n :\in h P : [] then P is robustly safe. 



D. Proofs 

D.l. Proof of Theorem 1 

A consequence of the types translation for our calculus is that [A] is isomorphic to Un for all types A. 
Formally, 

Lemma 3. [A] <:> Un h for all types A. 

In practice, this means that we can replace [A] by Un in type derivations, and vice versa. 

Some general remarks on typing are in order. A consequence of Lemma 3, as well as our general use of 
types, reveals that we rely on typing exclusively to show security properties, not to establish standard safety 
results. For instance, we do not use types to ensure that the type of the arguments supplied at method 
invocation match the type of the parameters to the method. Indeed, the only channel type in our translation 
has itself type Un. 

In order to prove Theorem 1, we first establish some lemmas. 
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Lemma 4. 

(1) UE\-v:A then E prin , (Ej h [v] : [A]. 

(2) If E h a : A and E , [Ej h p : Prin and fc £ dom(E , [£]) then: 

£o,[£],fc:Unr-fa]£ : [] 

(3) If c G Class and i G dom (methods (c)) then £7 h I c i aS s(c,£) ■ []• 

(4) If w G WebService then £o h I ws (w) : []. 

Proof. (1) We prove this by induction on the height of the type derivation for E \- v : A: 

- Case v — x: Since E \- x : A, we must have x:A G -E 1 . By definition of the translation for environment, 
x:[Aj G [£], hence E prm , [Ej h a; : [A], as required. 

- Case w = n«ZZ: We have E h nwZZ : c. Since [c] = Union(nMZ/(), c(Un)) and {null} — nullQ, we have 
Eprin, {Ej h nuZ/() : Union(miZ/(Un), c(Un)), as required. 

- Case v = new c(v\, . . . ,v n ): Since E \- v : A, where A = c, we have fields(c) = /, A,- l and 
£ h fi : A t for all i G l..n. Let E' = E prin , {Ej. By induction hypothesis, E' h {v t j : (A t j for all 
i G l..n. We can now derive: 

E> h M : [Aj Vi G l..n 
E l h{\v 1 l...,lv n \):{\A 1 \,...,\A n \) 
g^M^.M : (Un,...,Un) 

g'h : Un 

£' r-c([ui],...,[u„]) : Union(n«/i(Un),c(Un)) 

- Case v ~ p: Since E h p : A (with A = Id), we have p G Prin, hence p:Prin G E prin . Since [Id] = Prin, 
we have E prin , [E] hp: Prin, as required. 

(2) Again, we proceed by induction on the height of the type derivation for E h a : A. 

- Case a — v. We can apply the result of part (1). Since E h v : A, then E prin , [£] h [u] : [A]. We can 
derive: 

Eg, [Ej h [t,] : {A] 
g ,[i;],/c:Unhfc:Un go, [Ej h |tjj : Un 
£ ,[£],fc:Un h out k \v\ : [} 

- Case a — let x=a in b: We have E h a : B for some £>, and E,x:B \- b : A. Applying the 
induction hypothesis, we derive E , [£], fc':Un h [a ]£, : [] and £ , {Ej, x:[Bj, k:Un h [6]£ : []. Let 
£" = E , [£], fc:Un. We can now derive: 

E',k':Un,x:lBjh[b] p k :[} 
E', fc':Un h k' : Un £", fc':Un, a;:Un h [&]£ : [] 
E', fc':Un h [a]P : [] g fc':Un h inp k' (x:Un); jfrjf 7j] 

fc':Un h [a]P | inp k' (x:Un); jg : [] ~ 
E' h new (fc':Un); {{af k , | inp fc' (z:Un); \bf k ) : [] 

- Case a = if u = v then do eZse oi: We have E h u : B, E \- v : B, E h ao : A, and E h oi : A 
Applying the induction hypothesis, we derive Eo, fEj, k:Un h [ao]^ : [] and I?o, [£], fc:Un h [ao]^ : []• 
By (1), we also have E , [Ej h [u] : [B] and Eo, [E] h [v] : [B\. This gives us E , {Ej,k:Un h if [u] - 
[vj then [oo]fe else [ai]£ : [], as required. 

- Case a = u./j: We have £ h u./j : where E h v : c and fields (c) =/jH Ai ie1 -". By (1), £ , h 
[w] : [c]. Let I?' = £ , [B],fc:Un. First, let us derive that E',y: Un h split y is (xi:[Ai], . . . ,x n :\A n \); 
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out k Xj : []. Let E" — xi:[Ai}, . . . , x n :|L4 n ]. (We trim environments where possible to reduce clutter.) 



E',y:Un,E"\- Xj : [A,-] 
E'Y- fc:Un E', y : Un, E" h Xj : Un 
£',?/: Un h y : Un : Un,£" h out fc x~ : [] 

E',y : Un h split y is (xi:|L4i], . . . , x„:|L4„]); out fc x 3 : [] 



We can now derive: 



E' h [«] : Union(nuK(Un),c(Un)) 
E',y: Un h stop : [J 

E',y : Un h split y is (xi:[Ai], . . . , i„:[A„]); out fc xj : [] 

E' h case [w] is ra^/(y:Un); stop 

is c(y); split y is (xi:|L4i], . . . , i„:[i„]); out k xj : [] 



- Case a = v.£j{u\, . . . , u m ): We have E h v.£j(u\, . . . , u m ) : B, where E h v : c, methods(c) = 
£i i— > (sig i ,b i ) — £>(Ai xi, A m x m ), and £7 h Ufe : Afe for all k G l..m. By (1), 

So, r- [itfel : {A k j for all k G l..m. Let £' = So, [S],fc:Un. First, let us derive that E',y:Un h 
outai(p,H,[«i],..., [«„],*;):[]. 



y:Un h cJ : Un E' , y:Un h (p, H, . . . , [u„], fc) : Un 
£',y:Unhout cJ (p, H, . . . , [«„], fc) : [] 



We can derive: 



£' h [«] : Union(n«//(Un),c(Un)) 
£',y:Un h stop : [] 

y:Un h out c.l (p, [y\, . . . , K], fc) : [] 

£" h case [w] is null(y:\Jn); stop 

is c(y);out cj (p, [v], [wi],..., [u„],fc) : [] 



- Case a — w:£j(u\, . . . ,u m ): We have E h w:£j(ui, . . . ,u m ) : B, where class(w) — c, owner(w) = q, 
methods(c) =1; h (sig i ,bi) * el -- n , sj^. = B{A\ x\, . . . ,A m x m ), and E h Uk : Ak for all fc G l..m. 
By (1), E , fEj h [life] : {Akj for all fc G l..m. Rather than giving the full type derivation for the 
translation of a web service call, we outline the derivation of effects: 
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new (fci:Un, /c2:Un, <:Un, n p :Public Challenge []); 
// Effect: [check Public n p ] 

begin req(p,q,w,e(lui}, [w„]),t); 

/ / Effect: [check Public n p , end req(p, q, w, ^([iti], ■ • ■ , t)] 
out w (req(getnonceQ), ki); 

1 1 Effect: [check Public n p , end req(p, q, w, ^([iti], ■ • ■ , [u„]), t)] 
inp fci (res(geinonce(n 9 :Un))); 

/ / Effect: [check Public n p , end req(p, q, w, ^([tti], . . . , [«„]), <)] 
cast n 9 is (n^Public Response [end reg(p, q, w, £([uij, . . . , *)]); 
// Effect: [check Public n p ] 

out w (p, {req(w, . . . , [tt„]), i, n' q )} Kpq ,n p , fc 2 ); 

// Effect: [check Public n p ] 

inp fc2 (q':Un, &d?/:Un); 

// Effect: [check Public n p ] 

decrypt fcrfy is {res(plain)} k pq ', 

II Effect: [check Public n p ] 

match plain is (w, rest: 

(r:Res(w), t':\Jn, Public Response [end res(p, q, w, r, t')])); 
II Effect: [check Public n p ] 
split rest is (r:Res(w),rest': 

(i':Un, n' : Public Response [end res(p, q, w, r, t')])); 
II Effect: [check Publ ic n p \ 

match rest 1 is (t, n^Public Response [end res{p,q,w,r,t)}); 
II Effect: [check Public n p ] 
check n p is n' p ; 

II Effect: [end res(p,q,w,r,t)} 

end res(p, q, w, r, t); 

If Effect: [] 

case r is £(x); out k x 

If Effect: [] 

(3) Recalf that we assume that method bodies are weil-typed, that is, we assume for c, £j with methods(c) = 
li i— ► {sig i , bi) and si^ = B(A\ oi, . . . , A m x m ), that thisic, X\\A\, . . . , x m :A m h &j : B. By clause (2) 
above, this means that B , £/ws:[c], xi:[L4i], . . . , x m :[L4 m ], fc:Un h [&,]|! : []. Applying Lemma 3, we derive 
Eo, this :U r\,x i :(Jn, . . . , x m :Un, fc:Un h : []. We can now easily derive the following: 

B , z:Un h z : (Prin, Un, . . . , Un) 

Eo, z:Un,p:Prin, f/ws:Un, xi:Un, . . . , x„:Un, fc:Un h : [] 
.Bo I - : Un Bo, z:Un h split z is (p:Prin, this:(Jn, xi:lln, . . . , x n :lln, fc:Un); [bj]fa : [] 
Bo h repeat inp cJ? (z); split z is (p:Prin, £/us:Un, xi:lln, . . . , x„:Un, fc:Un); : [] 

B h 1 class (c, I) : [] 



(4) Let w e WebService, with owner (w) = q. First, note that the following derivation is admissible: 



E ,E\-p: Prin E ,E \- a : Req(w) B , E,r:Res{w) h P : es 
B , B h let r: i?es (w)=ca I U(p, a);P : es 



(The proof is a straightforward, if longish, type derivation.) Rather than giving the full type derivation 
for the implementation of web service w, we outline the derivation of effects: 
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repeat inp w (bdy.Un, fcitlln); 

// Effect: [] 

case bdy is req(getnonceQ); 
II Effect: [] 

new (ra^Public Challenge []); 

// Effect: [check Public n q ] 

out ki (res(getnonce(n q ))); 

II Effect: [check Public n q ] 

inp w (p':Un, cipher:Ur\, n p :Un, fc 2 :Un); 

// Effect: [check Public n q \ 

UpePr in tiP = P f then 

// Effect: [check Public n q ) 

decrypt cipher is {req(plain)} K pq ', 

II Effect: [check Public n q ] 

match plain is (w, rest: (a:Req(w), i:Un, 

Public Response [end req(p, q, w, a, i)])); 
If Effect: [check Public n q ] 

split rest is (a:Req(w),t:Un,n' q :Pub\\c Response [end req(p,q,w,a,t)])\ 
II Effect: [check Public n q ] 
check n q is n' q ; 

If Effect: [end req(p, q 7 w, a, t)] 
end req(p, q, w, a, t); 
I) Effect: [] 

let r:Res(w)=ca\\ w (p, a); 

// Effect: [] 

begin res(p,q,w,r,t); 

II Effect: [end res(p 7 q, w, r, t)] 

cast n p is (n^Public Response [end res(p, q, w, r, t)]); 
If Effect: [] 

out k 2 (q,{res(w,r,t,n' p )} Kpq ) 
II Effect: [] 

□ 

Lemma 5. If h a : A and p e Prin and fc ^ dom(E ) then: 

E WS7 Ep r i n \~ new {E c i ass , Ef~ e y S *)', (I c lass I ^ius 

| new (fc:Un); [a]^) : [] 
Proof. This is a corollary of Lemma 4. Specifically, we can derive: 

Eph- 1 ^{0, 1) : []M)^Mea E^I ws {w) : [petVebSer^ £ ,A::Unl-[ a ]% : [] 

E ^ I c i ass : [] E Q \-I WS : [] £ h new (fc:Un); Ia]| : [] 

E \- I class | Iws | new (fc:Un); [a]£ : [] 
E ws ,E prin h new (E c iass, E keV s); {hiass | /«, s I new (fc:Un); {a\ p k ) : [] 

□ 

We can now prove Theorem 1. 
Theorem. If h a : A and p <E Prm and k ^ dom(Eo) then the system 

new (£ ciass ,£ fee!/s ); (ic; oss | Iws | new (fc:Un); [a]jj!) 
is robustly safe. 
Proof. By Lemma 5, 

E ws , Ep r i n h~ new (E class i -^fceys); {I class | ^ws 

I new (fc:Un); [a]£) : []. 

Robust safety of the system follows by Theorem 7. □ 
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D.2. Proof of Theorem 2 

Theorem. If h a : A and p 6 Prin and k ^ dom(E ) then the system 

new {E class ,E keys ); (I net \ I c i ass | I ws | new (fc:Un); [aj p k ) 
is robustly safe. 



Proof. Rather than giving a full proof, we point out the parts of the proof of Theorem 1 that need to be 
updated. Essentially, we need to show that the new semantics for web method invocations is effect-free, and 
similarly for the new implementation of web services. These occur in the proof of Lemma 4, part (2) and (4). 

As we did in Lemma 4, rather than giving the full type derivation for the translation of a web service 
call, we outline the derivation of effects: 

new (fci:Un,fc2:Un,t:Un,n p :Public Challenge []); 
// Effect: [check Public n p ] 

begin reg(p,g,«;,^([ui], . . . , [tt„]),t); 

/ / Effect: [check Public n p , end req(p, q, w, . . . , [«„]), t)) 

out w (CertVKp, n p , req(getnonceQ), ki); 
II Effect: [check Public n p ,end req(p, q, w, ^([wi], ■ • ■ , [««]), t)] 
inp k\ (c:Un, res(getnonce(n q :Un))); 

If Effect: [check Public n p ,end req(p, q, w, ^([wi], . . . , [m„]), t)] 
decrypt c is {| cert:(q' :Un, Decrypt Key(AuthMsg(q')))^ VKCA -i; 
If Effect: [check Public n p ,end req(p, q, w, ^([wi], . . . , [« n ]), t)] 
match cert is (q, vkq: Decrypt Key(AuthMsg((7))); 
/ / Effect: [check Public n p , end req(p, q, w, . . . , [«„]), t)] 

cast n q is (n^:Public Response [end req(p, q, w, ^([ui], . . . , [««]), t)]); 
If Effect: [check Public n p ] 

out w (p, {|reg(w,£([ui|, . . . , [u„]), t, q, n' q )$ S K P , k 2 ); 
II Effect: [check Public n p ] 
inp k 2 (q":Un, bdy.Un); 
If Effect: [check Public n p ] 

decrypt bdy is Q res (plain :(w':Un, r:Un, i':Un,p':Un, 

Public Response [end res(p' ,q,w' ,r,t')]))§ vkq -i; 

If Effect: [check Public n p ] 

match plain is (w, rest:(r:Res(w), i':Un,p':Un, 

Public Response [end res(p', q, w, r, t')])); 
II Effect: [check Public n p ] 
split rest is (r : Res (w), rest' :(t':Ur\,p':Un, 

Public Response [end res(p', q, w, r, t')])); 

II Effect: [check Public n p \ 

match rest' is (t, rest":(p':Un, Public Response [end res(p' , q, w, r, i)])); 
// Effect: [check Public n p ] 

match rest" is (p, n p :Public Response [end res(p, q, w, r, t)]); 
II Effect: [check Public n p ] 
check n p is n' p ; 

If Effect: [end res(p, q, w, r, t)] 

end res(p, q, w, r, t); 

II Effect: [] 

case r is £(x); out k x 

II Effect: [] 

For the new implementation of web service w, rather than giving the full type derivation, we outline the 
derivation of effects: 
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repeat inp w (c:Un, n p :Un, bdy.Un, k\:Un); 

II Effect: [] 

case bdy is req(getnonceQ); 
If Effect: [] 

decrypt c is {|p:Un, wfcp:Decrypt Key(AuthMsg(p))|} yA - Cyi -i; 
// Effect: [] 

new (n g :Public Challenge []); 

// Effect: [check Public n q ) 

out fci (CertVKq, res(getnonce(n q ))); 

II Effect: [check Public rc g ] 

inp w (p':Un, cipher:Un, A;2:Un); 

// Effect: [check Public n q ] 

if p = p' then 

// Effect: [check Public n q ] 

decrypt cipher is {\req(plain:(w:Un, a:Un, t:Un, q':Un, 

Public Response [end req(p, q', w, a, t)]))\} vkp -i ; 

// Effect: [check Public n q ] 

match plain is (w, rest:(a:Req(w), t:Ur\, g':Un, 

Public Response [end req(p, q' , w, a, t)])); 
II Effect: [check Public n q ] 
split rest is (a:Req(w), 

t:Ur\, rest':(q':Un, Public Response [end req(p, q' , w, a, t)] j); 
II Effect: [check Public n q ] 

match rest' is (q, n^Public Response [end req(p, q, w 7 a, t)]); 
II Effect: [check Public n q ] 
check n q is n' q ; 

II Effect: [end req(p,q,w,a,t)} 
end req(p, q, w, a, t); 
II Effect: [] 

let r:Res(w)=ca\\ w (p, a); 

II Effect: [] 

begin res(p, q 7 w, r, t); 

II Effect: [end res(p, q,w,r 7 t)} 

cast n p is (n^Public Response [end res(p, q, w, r, t)]); 
II Effect: [] 

out k 2 (q,{\res(w,r,t,p,n' p )WsKq) 
II Effect: [] 

□ 



D.3. Proof of Theorem 3 

Theorem. If h a : A and p £ Prin and k ^ dom(Eo) then the system 

new {E class ,E keys ); (I net \ I c i aS s \ I ws I new (fc:Un); [af k ) 
is robustly safe. 

Proof. Rather than giving a full proof, we point out the parts of the proof of Theorem 1 that need to be 
updated. Essentially, we need to show that the new semantics for web method invocations is effect-free, and 
similarly for the new implementation of web services. These occur in the proof of Lemma 4, part (2) and (4). 

As we did in Lemma 4, rather than giving the full type derivation for the translation of a web service 
call, we outline the derivation of effects: 
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new (fci:Un, fc 2 :Un, t:Un, n p :Public Challenge []); 
// Effect: [check Public n p ] 
begin req(p,q,w, edmj, 

// Effect: [check Public n p ,end req(p, q, w, ^([wi], ■ • ■ , t)] 
out w (CertEKp, req(getnonceQ), fci); 

// Effect: [check Public n p , end req(p, q, w, ^([wi], . . . , [«„]), t)] inp fci (c:Un, cipher:Un, res(getnonce(n q :Un 

II Effect: [check Public n p ,end req(p, q, w, ^([tti], . . . , i)] 

decrypt c is {| ceri:(g':Un, Encrypt Key(AuthEncMsg(g')))[} vttcm- 1 ; 

// Effect: [check Public n p ,end reg(p, q, w, ^([ui], . . . , i)] 

match cert is (g, efcg:Encrypt Key(AuthEncMsg(g))); 

// Effect: [check Public n p ,end req(p, q, w, ^([wi], ■ • ■ , [w n ]), i)] 

decrypt cipher is {|ms<? 2 (?':Un, HK:Un)| Mp -i ; 

// Effect: [check Public n p ,end reg(p, g, w, ■ • ■ , [««]), t)] 

\f q = q' then 

// Effect: [check Public n p ,end req(p,q,w,£([uij, . . . , [w„]),i)] 

cast n q is (n^:Public Response [end req(p 7 q, w, ^([ui], . . . , [u„]), i)]); 

// Effect: [check Public n p ] 

new (if :SKey(p, q, w)); 

// Effect: [check Public n p ] 

witness K:SKey(p, q, w); 

If Effect: [check Public n p , trust K :SKey(p, q, w)] 

cast riK is (n^:Private Response [trust K:SKey(p, q, w)]); 

II Effect: [check Public n p ] 

out w {^msg 3 {w,p,t 1 K 1 n l K )^ ekq ,n pi {req(w 1 i{{u 1 \, [«„]), t, n' q )} K , fc 2 ); 

// Effect: [check Public n p ] 

inp fc 2 (bdy.Un); 

II Effect: [check Public n p \ 

decrypt bdy is {res (plain :(r: Res (w),t':Un, 

Public Response [end res(p 7 q,w,r,t')]))} K ; 

II Effect: [check Public n p ] 

match plain is (r:Res(w), rest:(t':Un, Public Response [end res(p, q, w, r, t')})); 
II Effect: [check Public n p \ 

match rest is (i,n p :Public Response [end res(p, q, w, r, t)]); 
If Effect: [check Public n p ] 
check n p is n' p ; 

If Effect: [end res(p, q, w, r, t)] 

end res(p, q, w, r, t): 

II Effect: [] 

case r is £(x); out k x 

II Effect: [] 

For the new implementation of web service w, rather than giving the full type derivation, we outline the 
derivation of effects: 

repeat inp w (c:Un, bdy.Un, fci:Un); 

// Effect: [] 

case bdy is req(getnonce()); 
II Effect: [] 

decrypt c is {|p:Un, efcp:Encrypt Key(AuthEncMsg(p))|} vkca- 1 > 
// Effect: [] 

new (n g :Public Challenge []); 

// Effect: [check Public n q ] 

new (riK :Private Challenge []); 

// Effect: [check Public n q , check Private tik] 

out fci (CertEKq, §msg2{q 1 nK)\i ekp, res(getnonce(n q )))] 

II Effect: [check Public n q , check Private n K ] 
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inp w (cipher ^Un, n p :Un, cipher 2 :Un, fc2:Un); 
// Effect: [check Public n q , check Private %] 
decrypt cipher \ 

is {|ms<7 3 (p/am 1 :(u':Un,p':Un, if Top, 

Private Response [trust K :SKey(p', q, w)]))\} DKq -i ; 
// Effect: [check Public n 9 , check Private n^] 
match plain 1 is (w, resi:(j/:Un, K.Top, 

Private Response [trust K :SKey(p', q, w)])); 
II Effect: [check Public n q , check Private Uk] 

match rest is (p, rest':(K :Top, n^-:Private Response [trust K:5Key(p, g, w)])); 

// Effect: [check Public n q , check Private %] 

split res£' is (if:Top, n^:Private Response [trust K :SKey(p, q, w)]); 

II Effect: [check Public n q , check Private n^r] 

check tik is ra^-; 

// Effect: [check Public n q , trust K:SKey(p, q, w)} 

trust ^ is (K':SKey(p, q, w)); 

II Effect: [check Public n q ] 

decrypt cipher^ is {req(plain 2 -(a:Req(w),t:Un 7 

Public Response [end req(p, q, w, a, i)]))}if; 

// Effect: [check Public n q ] 

split plain 2 is (a: Req(w) 7 t:Un, n^:Public Response [end re<?(p, q, w, a, t)]); 
II Effect: [check Public n q ] 
check n q is n'^; 

// Effect: [end req(p,q,w,a,t)} 
end req(p, q, w, a, t); 
II Effect: [] 

let r:Res(w)—ca\\ w (p, a); 

// Effect: [] 

begin res(p,q,w,r,t); 

II Effect: [end res(p, q, w 7 r, t)} 

cast n p is (n^Public Response [end res(p, q, w, r, t)]); 

II Effect: [] 

out k 2 {res(r,t,n' p )} K ' 

II Effect: [] 

□ 

E. First-Class Web Services 

The model of web services captured by our calculus in Section 3 does not consider web services to be values. 
This reflects the fact that current WSDL does not allow for web services to be passed as requests or results. 
On the other hand, a web service has a simple representation as a string, namely the URL used to access the 
web service, and this string can be passed as a request or a result. Hence, it is possible, in a sense, to pass 
web services as values given the current web services infrastructure. In this section, we explore an extension 
of our object calculus that allows web services as first-class values. The main point here is to show that there 
is no real difficulty in modelling this aspect of the web services infrastructure. Our main result is type safety. 
We expect it would be straightforward to translate this extended calculus into the spi-calculus, but we do 
not describe this in detail. 

For the sake of keeping this section essentially self-contained, we give the full syntax and semantics of 
the extended object calculus. 

E.l. Syntax 

We assume finite sets Prin, WebService, Class, Field, Meth of principal, web service, class, field, and method 
names, respectively. 
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Classes, Fields, Methods, Principals, Web Services: 



c G Class 

f G Field 

£ e Meth 

p G Prm 

w G Web Service 



class name 
field name 
method name 
principal name 
web service name 



There are now three kinds of data type: Id is the type of principal identifiers, c G Class is the type of 
instances of class c, and WS(c) is the type of web services with implementation class c G Class. A method 
signature specifies the types of its arguments and result. 

Types and Method Signatures: 



A,B G Type ::= 
Id 



WS{c) 
sig G Sig ::- 



B(A 1 xi,...,A n x n ) 



type 

principal identifier 
object 
web service 
method signature (xj distinct) 



As in Section 3, an execution environment defines the services and code available in the distributed 
system. 

Execution Environment: (fields , methods , owner , class) 

fields G Class — ► (Field ^5 Type) 

methods G CZoss — > (Meth -3 Sit? x Body) 
owner G WebService — ► Prm 
dass G WebService — > CZass 



fields of a class 

methods of a class 

service owner 

service implementation 



The owner and implementation class of a web service need not be globally known. We can assume that 
the representation of a web service w carries representations of its owner and its implementation class, which 
class and owner simply read off. Since we assume web services are given, and we do not provide for ways to 
actually create new web services, there is no loss of generality in taking this particular approach. 

The syntax of method bodies and values is that of the original object calculus, with the differences that 
web services are values, and that we do not assume that web service invocations require a fixed web service. 

Values and Method Bodies: 



x,y,z 

u, v G Value ::= 

x 

null 

new c(vi, ...,v n ) 

P 
w 

a, b G Body ::= 

v 

let x=a in b 

if u = v then a else b 

v-f 

v.£(ui, . . . ,u n ) 
v:l{u\, ...,u n ) 
p[a] 



name: variable, argument 
value 

variable 

null 

object 

principal identifier 
web service 
method body 
value 

let-expression 

conditional 

field lookup 

method call 

service call 

body a running as p 



We again require a method body of the form p[a], meaning p running body a, to keep track of which 
principal is running a method body in the upcoming operational semantics. 
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E.2. Operational Semantics 

The operational semantics is defined by a transition relation, written a — > p a' , where a and a' are method 
bodies, and p is the principal evaluating the body a. 

Transitions: 

'(Red Let 1) (Red Let 2) (Red If) ' 
a a' 

let x=a in b let x=o! in b let x=v in b ~^ p b{x^v} if u = v then a tr ue else o/ a ; se -^- p a u=v 
(Red Field) 

fields (c) = /ji-> ij' eL " jel..n 
(new c(vi, . . .,v n )).fj -^ p vj 

(Red Invoke) (where v = new c(v\, . . . , v n )) 
methods(c) = tj i-» (sig^bj) iel -- n j g \..n sig^ = B[A\ x\, . . . ,A m x m ) 

v.£j(ui, . . .,u m ) b-j{this<-v,x k ^u k kel - m } 

(Red Remote) (Red Prin 1) (Red Prin 2) 

owner(w) = q class(w) = c a a' 

w:£(ui, . . . ,u n ) -^ p q[new c(p).£(ui, . . . ,u n )] q[a] -^ p q[a'] q[v] ~-> p v 



E.3. Type System 

The judgments of our type system all depend on an environment E, that defines the types of all variables 
in scope. An environment takes the form xf.A\, . . . , x n :A n and defines the type Ai for each variable x%. The 
domain dom(E) of an environment E is the set of variables whose types it defines. 

Environments: 

i 1 

D,E ::= environment 

empty 
E, x:A entry 
dom(x\:A\, . . . ,x n :A n ) = {x\, . . . ,x n } domain of an environment 

The following are the two judgments of our type system. They are inductively defined by rules presented 
in the following tables. 

Judgments E h J: 

E \- o good environment 

E h a : A good expression a of type A 

We write E h J when we want to talk about both kinds of judgments, where J stands for either o or a : A. 
The following rules define an environment Xf.Ai, . . . ,x n :A n to be well- formed if each of the names 
distinct. 

Rules for Environments: 

(Env 0) (Env x) (where x £ dom(E)) 
£ho 

0ho E,x:A\-o 

We present the rules for deriving the judgment E h a : A that assigns a type A to a value or method 
body a. These rules are split into two tables, one for values, and one for method bodies. 
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Rules for Typing Values: 



(Val x) (Val null) (Val WS) 

E = E 1 ,x:A,E 2 Eho Eho E h o class (w) = c 



E\- x : A Eh- null : c E h w : WS(c) 

(Val Object) (Val Princ) 

fields (c) = fj >-> Aj iel - n Ehv l :A i Vie l..n E h o 

£hnet»c(!)i,...,«„):c E V- p : Id 



Rules for Typing Method Bodies: 



(Body Let) (Body If) 

Eh a: A E, x:A \- b : B E h u : A E h v : A Eh- a : B EV-b:B 



E h let x~a in b : B E h if u = v then a else b : B 

(Body Field) 
Ehv.c fields (c) = fj^ Aj iel - n jel..n 
Ehv.fj-.Aj 

(Body Invoke) 
Eh v : c methods(c) = £ t i-> (sig t , bi) lE1 - n j g \.. n 
sig^= B{A\X\,. ..,A m x m ) E h u k : A k Vfc g l..m 
£ h vl {ui, . . .,u m ) : B 

(Body Remote) 

E h u : W^(c) (Body Princ) 

methods(c) =£i^ (sig t ,h) tel - n j G l..n £ha:i 
szg 7 = xi, . . . , A m x m ) E h m : Aj Vi g l..m _g |_ p j a j . ^4 

£ h v:£j(ui, . . . ,u m ) : B 



We make the following assumption on the execution environment. 
Assumptions on the Execution Environment: 



(1) For each w G WebService, fields (class (w)) = Callerld : Id. 

(2) No tagged expression p[a] occurs within the body of any method; 

such expressions occur only at runtime, to track the call stack of principals. 

(3) for each c G Class and each £ G dom (methods (c)) , 
if methods (c)(£) = (B(Ai xi,...,A n x n ),b), 
then this:c, x\\Ai, x n :A n h b : B. 

We can establish the soundness of the type system of this extended object calculus by essentially the 
same way we established the soudness of the type system of the original object calculus. Recall that a method 
body is null-blocked if it is of the form null.fj, null.£(ui, . . . ,u n ), let x=a in b (where a is null-blocked), or 
q[a] (where a is null-blocked). A method body is stuck if a is not a value, a is not null-blocked, and there 
is no a' and p such that a -^> p a'. We write a a 1 to mean that there exists a sequence a\, . . . , a n and 
principals pi, . . . ,p n +i such that a -^ Vl at -^ P2 ■ ■ ■ -^ Pn a n -^p^ 1 a'. 

Theorem 8 (Soundness). If h a : A, and a a', then a' is not stuck. 

Proof. A straightforward adaptation of the proof of Theorem 6, via corresponding Preservation and Progress 
theorems. □ 



To illustrate the usefulness of first-class web services, consider the following simple example, where the fact 
that web services can be passed as arguments to methods is quite natural. Suppose, as we did in Section 3, that 
there are two principals Alice, Bob G Prin, and a web service cal = http://mycalendar.com/CalendarService, 
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where we have class(cal) = CalendarServiceClass . The web service cal maintains an appointment calendar 
for principals. It offers web methods to query a principal's calendar for a free time slot, and to reserve time 
slots. More precisely, the service has the following interface: 

class CalendarServiceClass 
Id Callerld 

Bool Available(Id account, Time from, Time to) 

{check if selected time slot if free for account) 
Void Reserve(Id account, Time from, Time to) 

(reserve time slot for account) 

(We assume that the classes Bool, Time, and Void are provided in the execution environment. The details 
of their implementation are irrelevant to our discussion.) 

Suppose that Alice has an account on cal, and that she wants to make an appointment with a calendar- 
enabled banking service — that is, a banking service that offers a web method for scheduling appointments 
with a bank advisor via a calendar service. Consider a calendar-enabled version of the banking service 
of Section 3. Let w — http://bob.com/BankingService, where we have owner(w) — Bob and class(w) — 
BankingServiceClass . We add a web method MakeAppt to BankingServiceClass that takes as argument a 
time period during which the appointment is sought, and a calendar service that the banking service can 
query to confirm that a common free time slot is available between the client and the bank advisor. The 
interface of the augmented banking service is as follows: 

class BankingServiceClass 
Id Callerld 

Num Balance(Num account) 
if account = 12345 then 

if this. Callerld = Alice then 100 else null 
else . . . 

Time MakeAppt (Time from, Time to, WS {Calendar Service) cs) 
. . . cs . Available(CallerId , ...)... 

Hence, if Alice wants to make an appointment sometime within the next week, she could issue the web method 
call w: Make Appt(l 8/1 1/02:08:00, 23/11/02:17:00, cal). (We assume appropriate syntax for constants of type 
Time.) During the evaluation of this web method invocation, the implementation of MakeAppt will make 
calls to cal: Available to find a time slot suitable to Alice, and finally a call to cahReserve to reserve a time 
slot. A principal with an account on a different calendar service c would call w: MakeAppt passing in c as the 
calendar service. 
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